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ABSTRACT 


This  thesis  highlights  the  need  for  specific  guidance  and 
standards  in  the  U.  S.  Marine  Corps  local  area  network  (LAN) 
specification  and  selection  process.  Media,  topologies, 
components,  access  methods,  protocols,  standards  and  other 
technologies  are  used  to  characterize  the  current  technical 
environment.  A  strategy  for  LAN  specification  and  selection 
is  presented.  This  strategy  stresses  top-down,  user 
requirement,  protocol  performance  oriented  techniques  vice 
the  bottom-up,  technical  design  selection  oriented  tech¬ 
niques  in  use  today.  Thorough  documentation  of  user 
requirements,  higher-level  services,  higher-level  protocols, 
and  an  information  and  networking  strategy  along  with  other 
considerations  like  facilities/support,  expected  general 
performance,  network  management,  and  security  is  the  method 
proposed  for  preparation  of  a  complete  specification 
document.  A  centrally  coordinated  U. S.  Marine  Corps  speci¬ 
fication  and  design  database  is  also  proposed  to  ensure 
future  interoperability,  connectivity,  and  support. 
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A.  GENERAL 


The  world  around  us  is  undergoing  a  great  deal  of  change 
driven  by  the  increased  use  of  electronics,  especially 
computers.  Our  whole  working  environment  is  being  populated 
by  increasingly  complex  systems,  all  of  which  seem  to  be 
computer  controlled.  These  computers,  regardless  of  their 
scale,  are  nothing  more  than  data  processing  devices;  raw 
data  is  fed  in,  a  program  controlled  process  acts  on  the 
data,  and  the  processed  data  is  then  output  in  the  form  of 
usable  information.  The  evolution  in  computer  configuration 
and  usage  over  the  past  20-30  years  caused  a  veritable 
information  explosion.  This  explosion  was  not  only  a  result 
of  increased  computer  processing  capability  but  also  the 
ability  to  place  this  processing  capability  on  an  individual 
user ' s  desk. 

The  early  centralized  processing  techniques  involved 
simple  two  wire  configurations  from  card  readers  to  central 
processing  units  (CPU)  and  from  the  CPU  to  a  printer. 
Individual  jobs  were  dropped  at  the  computer  center  window 
and  picked  up  later  after  processing.  Simple  equipment 
configurations  were  easy  to  troubleshoot  and  maintain. 
Things  got  a  little  more  complicated  with  the  addition  of 
dat'a  communications  between  plotters,  remote  printers  and 
other  devices  directly  connected  to  the  CPU.  However,  all 
equipment  was  still  within  one  common  controlled  area  where 
maintenance  remained  easy  but  wiring  increased  in 
complexity.  Terminal  processing  came  next  and  along  with  it 
the  problem  of  allocating  an  individual  wire  pair  connection 
for  each  machine;  computer  networking  in  its  most  basic  form 
was  born.  Initially  handled  by  locating  all  the  terminals 
in  a  room  close  to  the  CPU,  data  communications  experienced 


the  first  significant  breakthrough  in  the  early  1960's  when 
users  began  to  separate  from  their  central  computer  systems. 
The  concept  of  time  shared  systems  with  multiple  users  at 
different  physical  locations  became  reality. 

In  the  early  1970's,  network  complexity  increased  when 
coaxial  cable  and  communications  devices  like  multi-drop 
lines,  multiplexors,  concentrators,  and  intelligent  terminal 
devices  were  used  to  enchance  and  extend  communications 
between  users  and  the  CPU.  As  the  number  of  users  increased 
so  did  the  communications  overhead  as  well  as  the  competi¬ 
tion  for  time  at  the  central  processing  unit.  The  growing 
network  of  cables  and  networking  equipment  increased  the 
maintenance  burden.  Special  computers  were  developed  to 
remove  the  communications  burden  from  the  CPU  and  CPUs  them¬ 
selves  were  made  faster  and  more  powerful.  However,  these 
improvements  could  not  keep  up  with  the  increased  user 
demand. 

The  intelligent  terminal  was  probably  most  instrumental 
in  the  move  away  from  large,  costly,  centralized  mainframe 
processing  systems.  A  sharp  decrease  in  size  and  cost  of 
computers  accompanied  by  specially  designed  functional  soft¬ 
ware  packages  freed  users  from  dependance  on  tiie  central 
computing  system.  It  also  gave  them  the  opportunity  to 
acquire  powerful  personal  computing  devices  in  large 
numbers.  Micro-computers  emerged  as  personal  productivity 
tools.  International  Data  Corporation' s  most  recent  esti¬ 
mates  on  computer  shipments  indicate  1986  U. S.  desktop 
personal  computer  (PC)  shipments  totalling  $14.2  billion 
will  exceed  the  $13.7  billion  expenditure  estimates  for 
mainframe  systems  [ Ref.  1:  p.  35]  . 

In  terms  of  cost-savings  and  processing  performance,  use 
of  personal  computers  has  many  advantages  over  the  tradi¬ 
tional  time  sharing  approach.  Higher  worker  productivity, 
better  computer  accessibility  and  availability,  faster 


responsiveness,  greater  interaction,  and  a  wider  choice  of 
equipment  are  all  advantages  of  the  new  PC  technology. 
Software  such  as  spreadsheets,  database  managers,  wordpro- 
cessors,  etc,  all  help  individual  users  produce  higher 
quality  work  easier  and  faster.  However,  along  with  these 
advantages  come  new  problems.  Expensive  peripheral  devices 
(printers,  mass  storage,  etc,  ),  connected  to  the  central 
processing  facility  and  so  long  taken  for  granted,  were  now 
needed  at  each  individual  workstation.  The  integrity  of 
data  files  previously  maintained  in  a  common  database  was 
duickly  compromised  by  individual  updates  performed  at 
different  times  and  in  different  ways  at  each  workstation. 
Sharing  data  went  from  simple  file  access  on  the  mainframe 
to  hand  carried  discs  from  workstation  to  workstation  or 
repeated  manual  database  generation  and  maintenance  at  each 
station.  Huge  mainframe  program  libraries,  previously 
centrally  maintained  and  accessable  by  all  users,  now  had  to 
be  reproduced  and  provided  to  each  individual  user  (if  his 
PC  had  the  memory  capability  to  use  them).  It  became 
obvious  that  using  the  PC  as  a  standalone  device  tapped  only 
a  fraction  of  its  potential  not  to  mention  the  disadvantages 
caused  by  separation  from  a  central  processing  and  control 
point.  Cost  effective  ways  of  linking  these  disparate 
sources  of  information  processing  and  storage  was  viewed  as 
the  next  logical  step  toward  increasing  productivity  through 
automation. 

Linking  individual  stations  to  host  computers  via  modems 
and  standard  telephone  lines  was  the  communication  and 
computer  industry's  first  attempt  at  solving  this  networking 
problem.  However,  the  speed  limitations(  usually  less  than 
1200  bits  per  second  (bps)  )  and  the  dependence  on  a  host 
computer  for  connection  to  other  users  made  this  technique 
an  inefficient  communications  solution.  Local  area  networks 
(  LAN)  are  now  emerging  as  the  logical  evolutionary  step  in 


development  of  a  shared  multi-user  network.  Although 
distinctly  different  from  the  traditional  time-shared 
processor  systems,  LAN  technology  is  quickly  approaching  the 
capabilities  and  applications  of  centralized  mainframe 
time-sharing  systems. 

LANs  have  been  around  since  the  middle  1970 's  when 
Datapoint  Corp.  introduced  its  first  version.  This  new 
networking  technique  promised  to  provide  a  flexible  way  to 
link  computers,  terminals,  printers,  memories,  etc,  so  they 
could  exchange  data  at  high  speeds  [Ref.  2:  p.  1401.  Since 
then  the  number  of  manufacturers  of  local  networks  or  local 
network  products  has  grown  to  over  200.  [Ref.  3:  p.  124]. 
These  vendors  offer  a  wide  variety  of  topologies,  control 
structures,  media,  access  control  techniques,  and  other 
items  supposedly  designed  to  suit  the  prospective  buyer's 
individual  needs.  They  offer  the  potential  for  more  flex¬ 
ible  connectivity  among  processors,  workstations,  storage 
devices,  and  expensive  peripherals  in  the  local  area.  These 
features  are  available  at  greater  speeds  and  lower  cost  than 
possible  in  the  previous  host-dependent  data  processing 
environment.  This  proliferation  of  vendors  has  generated 
many  innovative  and  useful  approaches  to  the  networking 
solution.  However,  the  differences  in  these  approaches  has 
caused  a  great  deal  of  confusion  on  the  part  of  prospective 
buyers.  They  have  also  caused  the  procurement  and  installa¬ 
tion  of  many  heterogeneous  networks  that  can't  support  the 
same  kind  of  equipment  and  can't  intercommunicate. 

In  many  ways,  LAN  technology  is  still  in  its  infancy. 
Most  vendors  today  provide  a  transmission  medium  with  low 
level  protocols  either  compatible  with  other  products  they 
produce  or  specially  designed  to  suit  a  specific  user  commu¬ 
nity.  Some  have  attempted  to  adopt  "open  systems"  capable 
of  connecting  a  wide  variety  of  user  equipment.  None, 
however,  have  a  design  that  will  soon  become  the  standard  or 


clear  cut  solution  to  everyone  s  needs.  Protocol  layered 
networking  architectures  like  the  Open  Systems 
Interconnection  Reference  Model  (OSI/RM)  of  the 
International  Standards  Organization  ( ISO)  provide  a  general 
structure  of  protocol  definition  [Ref.  4:  p.  2-3].  The 
painfully  slow  process  of  high  level  protocol  standards 
development  from  sources  like  the  Institute  of  Electrical 
and  Electronics  Engineers  ( IEEE)  Computer  Society  has 
resulted  in  the  adoption  of  several  "defacto"  standards  by 
developers  who  hope  they  will  be  officially  sanctioned  at 
some  point  in  the  future.  Many  buyers  think  that  they  will 
simply  go  out  and  buy  the  latest  technology  only  to  discover 
that  the  advertised  compatibility  is  only  at  the  physical 
and  link  layer  of  the  ISO  OSI  model.  Higher-level  protocols 
that  allow  intermachine  and  inter-LAN  communications  are  not 
yet  supported. 

B.  THE  PROBLEM 

Many  organizations  within  the  U. S.  Marine  Corps  are 
looking  for  ways  to  improve  their  personal  productivity  and 
information  sharing  capabilities.  The  need  for  data  commu¬ 
nications  connectivity,  particularly  among  personal 
computers  and  office  automation  equipment,  is  growing  daily. 
The  current  Marine  Corps  Data  Network  (MCDN),  which  is  based 
on  IBM' s  System  Network  Architecture  ( SNA)  and  pre-SNA 
architectures,  cannot  totally  and  efficiently  meet  the  needs 
of  these  new  asynchronous  devices.  LANs  are  the  most  often 
mentioned  solution  to  this  problem  but  no  official  guidance 
on  LAN  standards  has  been  published.  It  is  very  difficult 
to  develop  the  thorough  specifications  needed  to  define 
requirements  and  solicit  vendor  solutions  using  only  the 
confusing  and  inflated  manufacturer  advertisements. 
Although  applications  should  drive  network  design,  many 
"system  hunters"  find  themselves  developing  broad  or 
superficial  requirements  then  comparing  and  evaluating  the 


capabilities  of  existing  hardware  and  software  solutions  to 
satisfy  these  requirements.  As  a  result,  thorough 
definition  of  user  needs  is  never  accomplished. 

Initially,  purchase  of  individual  productivity  tools 
such  as  office  automation  products  and  individual  intelli¬ 
gent  workstations  (PCs)  was  basically  decentralized.  The 
wide  variety  of  vendor  products  permitted  wide  variations  in 
capabilities.  The  cost  for  these  tools  was  not  particularly 
high  and  organizations  basically  used  them  to  improve 
productivity  within  their  own  span  of  control.  This  had 
little  affect  on  other  organizations.  Now  these  produc¬ 
tivity  tools  are  moving  from  low  cost,  individual,  equipment 
elements  to  costly,  sophisticated,  equipment  networks 
designed  to  increase  productivity  through  information 
sharing  and  reduce  expenses  by  sharing  use  of  high  cost 
peripheral  devices.  The  cost  of  special  cables,  interface 
devices,  and  sophisticated  servers  along  with  individually 
purchased  maintenance  and  support  contracts  are  rapidly 
off-setting  the  advantages  of  low  cost  individual  work¬ 
stations  over  the  traditional  mainframes  approach.  The 
specification  and  selection  of  these  networks  deserves  more 
detailed  consideration  and  guidance  than  broadly  specified 
user  requirements  augmented  by  technical  specifications 
detailing  vendor  strategies  that  already  exist. 

The  current  LAN  procurement  process  seems  to  be  an 
extension  of  the  PC  procurement  process  aimed  primarily  at 
solving  a  local  need.  There  is  little  or  no  immediate 
concern  for  standardization  of  applications  and  communica¬ 
tions  procedures  to  facilitate  future  connectivity.  If  a 
new  telephone  switchboard  came  along  which  dramatically 
improved  local  telephone  switching  performance  for  a  base  or 
unit  but  reduced  the  ability  to  exchange  information  on  long 
distance  AUTOVON  and  commercial  networks  with  that  base  or 
unit,  would  we  permit  its  purchase? 


Permitting  LAN 


procurements  to  concentrate  only  on  local  individual  unit  or 
base  needs  and  applications  may  lead  to  serious  interoper¬ 
ability  and  growth  problems  in  the  future.  Interface  param¬ 
eters  for  inter-LAN  communications  as  well  as  existing  and 
evolving  wide  area  networks  (WAN)  should  be  considered  in 
all  LAN  procurements.  What  about  connectivity  via  alterna¬ 
tive,  available,  less  costly  means?  Digital  PBX's,  CATV 
systems,  and  scheduled  coaxial  and  fiber  optic  upgrades  to 
existing  base  cable  plants  are  often  overlooked  as  potential 
substitutes  for  sophisticated  and  costly  individual  LAN 
connection  and  transmission  systems.  Will  future  voice, 
data,  imagery,  and  video  requirements  be  satisfied  by  highly 
centralized  super  computers  and  integrated  voice  and  data 
computerized  telephone  exchanges;  by  distributed  voice  over 
data  local  area  networks  with  sophisticated  servers,  bridges 
for  inter  LAN  communications  and  gateways  to  mainframes  and 
long  distance  integrated  voice  and  data  networks;  or  by  some 
other  combination  of  these  maturing  advanced  technologies? 

This  thesis  highlights  the  need  for  specific  guidance 
and  if  possible  Marine  Corps  wide  standards  in  the  LAN  spec¬ 
ification  and  selection  process  by  detailing  the  many  tech¬ 
nical  and  logical  performance  issues  that  must  be  addressed 
when  1)  trying  to  make  near-term  individual  system  design 
decisions  and  2)  attempting  to  shape  the  long-term  evolution 
toward  a  more  effectively  integrated  network  design.  Media, 
topologies,  components,  access  methods,  protocols,  standards 
and  other  technologies  are  discussed  in  an  attempt  to  char¬ 
acterize  the  current  technical  environment.  A  strategy  for 
LAN  specification  and  selection  is  presented.  This  strategy 
stresses  top-down,  user  requirement,  protocol  performance 
oriented  techniques  vice  the  bottom-up  technical  design 
selection  oriented  techniques  in  use  today.  User  require¬ 
ments,  higher-level  services,  higher-level  protocols,  and  an 
information  and  networking  strategy  are  used  to  determine 


whether  a  LAN  is  the  appropriate  technology.  If  properly 
prepared,  LAN  specifications  directly  translated  from  user 
requirements  plus  other  considerations  like  facilities/ 
support,  expected  general  performance,  network  management, 
security  and  others  will  result  in  vendor  proposals  that 
address  needed  functional  requirements  vice  concentration 
on  their  own  system  features  and  functions.  A  centrally 
coordinated  LAN  specification  and  design  process  is 
needed  to  ensure  future  interoperability  and  connectivity. 


II.  BASIC  LOCAL  AfiEA 


A.  A  DEFINITION 

As  the  name  implies,  a  local  network  is  a  relatively 
short-distance,  high-speed  scheme  for  connecting  various 
computing  resources.  The  distances  covered  by  these 
networks  depend  on  the  products  used  and  generally  range 
from  a  few  hundred  yards  to  30  miles.  Using  the  word 
"local"  in  the  name  was  probably  done  to  contrast  this 
networking  technique  with  long-haul  telephone  and  data 
switching  networks. 

More  technically  defined,  a  local  area  network  is  a  data 
telecommunications  system  designed  to  network  a  number  of 
independent  devices  like  personal  computers,  printers,  mass 
storage  devices,  plotters,  host  computers,  terminals,  tele¬ 
vision  cameras,  television  receivers,  sensing  equipment,  and 
telephones.  They  are  usually  owned  by  a  single  organiza¬ 
tion,  restricted  to  small  geographic  areas  (a  building  or 
group  of  buildings),  and  use  moderate  to  high  data  rates  (1 
to  10  million  bits  per  second)  [Ref.  5:  p.  15].  They  are 
normally  subsystems  of  larger  information  processing  systems 
used  to  provide  data  transport,  switching,  and  network 
management  functions.  Many  support  a  wide  variety  of  appli¬ 
cations  like  file  editing  and  transfer,  graphics,  word 
processing,  electronic  mail,  database  management,  high  speed 
video,  and  digital  voice. 

Most  LANs  use  a  packet  transmission  technique  to  break 
messages  into  shorter  segments,  each  with  an  originating  and 
destination  address  code.  The  network  itself  consists  of 
some  form  of  communications  medium  (cable)  of  limited  length 
to  carry  transmissions  plus  interface  units  to  connect  all 
devices  served  by  the  network.  Some  permit  only  the  suppli¬ 
er's  terminals  and  processors  to  be  connected  while  others 


permit  any  manufacturer's  equipment  to  be  connected. 
Depending  on  the  access  scheme  used  to  control  the  medium, 
each  station  transmits  in  an  assigned  time  slot,  an  assigned 
order,  or  when  it  can  seize  control  of  the  medium  by 
competing  with  other  stations.  The  user  normally  purchases 
the  cabling  and  interface  units,  then  installs  and  maintains 
them  himself  or  arranges  for  installation  and  maintenance  by 
the  supplier.  Before  looking  at  a  strategy  for  specifying 
and  selecting  a  LAN,  an  introduction  to  the  major  technical 
features  and  functions  currently  available  is  in  order. 

B.  MEDIA 

The  transmission  medium  is  the  physical  connection 
between  components  in  the  network.  There  are  several  forms 
of  transmission  media  used  in  LAN  configurations  and  all 
have  earned  the  right  to  be  considered  due  to  their  respec¬ 
tive  advantages  and  disadvantages.  Among  the  most  familiar 
choices  are  twisted-pair  wire,  coaxial  cable,  and  fiber 
optic  cable. 

Selecting  the  appropriate  medium  is  often  a  critical 
decision  when  designing  a  computer  communications  network. 
Generally,  technology,  bandwidth,  connectivity  and  distance 
along  with  applications  and  cost  are  the  characteristics 
used  to  compare  the  different  media  choices.  These  factors 
enable  the  designer  and  prospective  buyer  to  evaluate  each 
medium  in  terms  of  performance  features  like  reliability, 
simplicity,  speed,  and  noise  immunity  as  well  as  ease  of 
installation,  maintenance,  and  reconfiguration. 

Most  signals  cannot  be  sent  in  their  original  form,  so 
some  sort  of  modulation  or  encoding  technique  is  required 
before  transmission.  Both  analog  and  digital  transmission 
methods,  each  of  which  has  its  own  unique  properties,  are 
used  to  propagate  signals  on  the  various  media.  Since  both 
methods  can  be  affected  by  attenuation  and/or  distortion 
during  transmission  due  to  the  physical  properties  of  each 


medium,  other  components  designed  to  offset  these  noise 
problems  must  be  considered.  Amplifiers,  repeaters,  and 
equalizers  are  often  used  to  compensate  for  signal  losses  or 
to  restore  distorted  waveforms  to  their  original  shape. 

The  signaling  speed  capability  on  the  media  is  often 
measured  in  the  width  o-f  the  signal  spectrum  it  can  handle 
or  more  appropriately,  its  bandwidth.  The  faster  the  signal 
can  change  with  respect  to  time,  the  faster  the  signal 
speed;  normally  measured  in  bits  per  second  (bps).  Higher 
signal  speeds  require  more  bandwidth  for  transmission. 

1.  Twisted-Pair  Cable 

A  twisted-wire  network  is  just  what  the  name 
implies:  a  network  of  twisted  wires  with  two  or  more  wires 
connecting  each  remote  device  in  a  point-to-point  fashion 
with  a  central  switching  or  processing  node.  The  wires, 
normally  made  of  copper,  have  a  thin  insulation  coating  and 
are  arranged  in  a  regular  geometric  pattern  (parallel  or 
spiral)  to  reduce  noise  and  ensure  that  the  electrical  prop¬ 
erties  are  constant  throughout  the  length  of  the  line.  Both 
analog  and  digital  signals  can  be  passed  in  twisted-pair  but 
due  to  its  limited  bandwidth  characteristics,  relatively 
slow  signal  speeds  are  achieveable.  If  analog  signals  are 
used,  modems  are  required  at  both  ends  to  first  modulate  the 
incoming  digital  information  into  analog  form,  transmit  it 
over  the  twisted-pair,  and  demodulate  the  signal  back  to  its 
original  digital  form  at  the  destination.  This  process, 
which  produces  relatively  slow  speeds  of  300-9600  bps  on  a 
normal  3  Khz  voice  channel,  is  most  commonly  used  for  data 
transmissions  through  Private  Automatic  Branch  Exchange 
(PABX)  telephone  switching  systems  designed  to  handle  analog 
voice  telephone  calls.  Recent  advances  in  Computerized 
Branch  Exchange  (CBX)  telephone  systems  which  employ  digital 
transmission  techniques  have  allowed  speeds  as  high  as 
64,000  bps  to  be  achieved  on  local  loops.  In  these  systems, 
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analog  voice  signals  are  converted  to  digital  signals  using 
pulse  code  modulation  (PCM)  techniques  for  digital  transmis¬ 
sion  while  the  digital  data  signals  are  already  in  a  form 
suitable  for  transmission  and  switching. 

Twisted  pair  is  often  the  least  expensive  per  foot 
to  install  over  short  distances.  However,  when  additional 
costs  for  line  conditioning  or  coding  equipment  used  to 
extend  the  range  and  speed  is  added  to  the  cost  of  the  wire, 
overall  installation  costs  approach  that  of  other  media  like 
coaxial  cable.  This  media  (using  analog  transmission  via 
modems  )  provides  the  transmission  backbone  and  in  some 
cases  the  terminal  interface  for  MCDN. 

2.  Coaxial  Cable 

Coaxial  cable,  like  twisted  pair,  has  two  conductors 
but  it  is  constructed  differently  to  permit  operation  over  a 
wider  range  of  frequencies.  It  consists  of  a  flexible 
conductive  cylinder  (shell)  with  an  inner  conductor  in  the 
center.  The  space  between  the  cylinder  and  the  inner 
conductor  is  filled  with  an  insulator  to  maintain  isolation 
between  the  conductors.  The  insulator  can  be  a  solid 
dielectric  material  or  air  with  dielectric  supports  an  inch 
apart  to  separate  the  conductors.  The  entire  cable  is  then 
encased  in  an  outer  insulative  casing  to  isolate  it  from 
outside  interference.  Larger  bandwidth,  lower  crosstalk, 
lower  line  loss,  and  better  immunity  to  electromagnetic 
interference  make  coaxial  cable  a  much  better  medium  than 
twisted  pair  for  faster  signal  speeds.  Based  on  the  modula¬ 
tion  technique  and  physical  network  structure,  coaxial 
cables  are  generally  classified  in  two  categories  :  baseband 
and  broadband. 

a.  Baseband 


Baseband  coaxial  cable  uses  a  solid  center 
conductor  with  a  woven  mesh  of  copper  as  the  outer  conductor 
and  is  normally  rated  in  the  50  ohm  grades.  This  is  the 


type  cable  used  for  home  cable  TV  or  that  used  to  connect 
terminal  devices  to  time-shared  host  computers.  Digital 
transmission  techniques  are  used  for  unidirectional,  single 
signal  transmission.  A  passive  transceiver  is  connected  to 
the  cable  with  a  nondestructive  tap  for  easy  attachment  and 
removal  without  permanent  damage  to  the  cable.  Baseband 
means  that  the  transceivers  drive  the  digital  data  signal 
directly  onto  the  cable  without  modulation.  Various  coding 
techniques  are  used  but  only  one  serial  bit  stream  can 
occupy  the  cable  at  one  time.  Data  rates  in  the  10-12  Mbps 
range  are  possible  because  the  single  bit  stream  occupies 
the  entire  cable  bandwidth.  This  high  data  rate  combined 
with  time  division  multiplexing  (TDM)  techniques  does  allow 
multiple  users  to  simultaneously  access  the  medium  with 
fairly  high  data  rates  and  minimal  delay  (more  detail  on 
access  techniques  is  presented  later).  Although  better  than 
twisted  pair,  information  transmitted  in  baseband  digital 
form  is  highly  susceptible  to  noise  and  requires  the  use  of 
repeaters  for  signal  regeneration.  This,  together  with 
acceptable  delays,  traffic  load,  and  network  configuration, 
normally  limits  the  distance  between  stations  and  repeaters 
to  one  to  three  kilometers  [Ref.  6:  p.  45].  Some  topologies 
accommodate  this  problem  better  than  others, 
b.  Broadband 

Broadband  coaxial  cable  is  the  same  construction 
as  baseband  cable  but  a  little  heavier  and  stiffer  making  it 
slightly  more  difficult  and  expensive  to  install.  It  is  the 
75  ohm  grade  cable  commonly  used  in  the  Community  Antenna 
Television  (CATV)  industry.  Because  of  this  common  use, 
broadband  systems  can  take  advantage  of  existing  CATV 
cabling  for  transmission  medium  plus  low  cost  signal  split¬ 
ters,  taps  and  repeaters  are  commercially  available  in  large 
numbers.  Broadband  cable  can  handle  either  analog  or 
digital  signals. 


Frequency  and  phase  modulation  techniques  are 
used  to  transmit  analog  signals  unidirectionally  on  the 
cable.  For  full  duplex  operation,  one  of  two  techniques 
called  midsplit  and  nontranslate  are  used.  With  midsplit, 
the  cable's  bandwidth,  normally  300-400  Mhz,  is  split  in 
half.  Signals  are  transmitted  on  one  half,  received  at  a 
central  retransmission  facility,  then  converted,  amplified, 
and  retransmitted  on  the  other  half  of  the  bandwidth  for 
receipt  by  all  stations.  Channel  assignments  are  made  by 
frequency  division  multiplexing.  This  allows  the  assignment 
of  the  entire  capacity  to  one  channel  or  the  bandwidth  can 


be  broken  into  several  subchannels. 


In  the  non- translate 


process,  two  cable  are  used;  the  signal  is  transmited  in  one 
direction  on  the  first  cable  and  received  in  the  other 


direction  on  the  second. 


The  cables  are  connected  to  a 


head-end  device  which  inverts  the  transmission  direction. 
Because  there  is  a  separate  cable  for  each  direction,  the 
total  bandwidth  of  the  cable  can  be  used  rather  than  half 
the  bandwidth  as  in  midsplit.  Using  the  entire  bandwidth 
for  one  channel  would  result  in  speeds  far  greater  than 
necessary  for  current  and  envisioned  future  network  require¬ 
ments.  Therefore,  allocation  to  multiple  subchannels  not 
only  makes  more  efficient  use  of  the  available  bandwidth  but 
also  dramatically  increases  the  number  of  potential  systems/ 
users  that  can  simultaneously  use  the  same  cable.  The  high 
frequency  analog  transmission  techniques  reduce  the  poten¬ 
tial  for  interference  suffered  by  digital  baseband  tech¬ 
niques  thereby  increasing  the  distance  possible  between 
nodes.  Typical  broadband  networks  can  cover  distances  of 
10-50  kilometers  [Ref.  6:  p.  45], 

3.  Fiber  Optics 

With  fiber  optics,  the  electrical  digital  or  audio 
analog  signal  is  converted  to  a  beam  of  light  in  the 
infrared  frequency  range.  This  light  signal  is  then 


transmitted  through  an  dptical  fiber  which  consists  of  a 
central  glass  or  plastic  core  with  a  high  refractive  index 
surrounded  by  a  cladding  with  a  slightly  lower  refractive 
index.  The  difference  between  the  core  and  cladding  acts 
like  a  mirror  for  the  light  ray.  The  light  transmission  is 
based  on  the  total  internal  reflection  of  light  as  it 
travels  along  the  core  of  the  fiber.  The  signal  is  trans¬ 
mitted  from  one  end  of  the  cable  to  the  other  regardless  of 
how  the  cable  is  curved  or  bent  [Ref.  6:  p.  47]. 

Semiconductor  lasers  and  light-emitting  diodes  (LED) 
are  the  two  main  light  generating  sources  used  in  this  tech¬ 
nology.  The  lasers  are  more  efficient  because  they  have  a 
narrower  beam  and  spectral  width  plus  they  have  faster 
optical  rise  and  fall  times  in  response  to  the  input  signal. 
However,  the  laser  has  a  shorter  operating  life  due  to 
higher  sensitivity  to  temperature  and  age. 

Broader  bandwidth,  lower  transmission  losses, 
smaller  physical  size,  lighter  weight,  better  immunity  to 
electromagnetic  interference,  greater  electrical  insulation 
and  better  security  are  all  advantages  that  fiber  optics 
enjoy  over  the  media  previously  discussed.  These  advantages 
make  it  a  prime  candidate  for  use  with  LANs  but  this  use  has 
been  restricted  by  high  costs  for  system  components  and 
technological  immaturity.  Slow  development  of  this  tech¬ 
nology  is  a  direct  result  of  poor  industry  standards. 
Different  manufacturers  producing  various  shapes,  sizes, 
grades  of  materials,  and  connectors  all  act  as  a  major 
obstacles  in  speeding  development  of  high-performance  fiber 
optics.  The  connectors  in  particular  have  been  a  major 
stumbling  block.  Basic  limitations  like  maximum  number  of 
tappings,  connection  attenuation  and  reflection,  plus 
vulnerability  and  link  failures  have  limited  fiber  optics 
use  [Ref.  7:  p.  1 1 1  —  62 ] .  Its  properties  make  it  very  useful 
in  long  haul  point-to-point  configurations  such  as  between 


LANs  or  nodes  separated  by  long  distances.  Future  continued 
development  of  this  technology  promises  the  potential  for 
increased  nodes  per  network,  faster  transmission  speed,  full 
bandwidth  utilization  and  lower  costs  for  node  hardware. 

4.  Other  Media 

Microwave  and  infrared  frequencies  transmitted 
through  the  atmosphere  have  also  been  considered  as  poten¬ 
tial  transmission  media  for  LANs.  Their  large  bandwidths 
make  them  particularly  suitable  for  high  speed  transmission. 
However,  the  added  cost  of  expensive  radio  or  light  trans¬ 
mission  equipment,  line  of  sight  transmission  requirements, 
plus  authorization  and  license  for  frequency  usage  make  them 
less  practical.  Table  I  [  Ref.  7:  p.  5 S J  offers  a  good 
comparison  of  the  media  discussed. 

C.  TOPOLOGIES 

Another  important  feature  of  LANs  is  topology  ( sometimes 
called  architecture)  or  the  way  in  which  network  stations 
are  interconnected.  It  is  best  defined  as  the  layout  of 
communications  links,  switching  elements,  and  nodes  which 
determine  or  define  the  path  used  to  exchange  data  between 
any  two  stations.  Since  by  definition  a  LAN  interconnects 
devices  in  a  small  area,  why  not  establish  a  direct  point- 
to-point  link  between  all  stations  that  need  to  communicate? 
This  is  the  philosophy  behind  a  mesh  topology  (Figure  2.1). 
If  all  stations  desire  to  talk  to  all  others,  the  disadvan¬ 
tages  of  this  concept  are  obvious.  The  cost  in  terms  of 
cable  installation  and  input/output  hardware  make  it  easy  to 
discard  mesh  topology  as  a  feasible  approach  just  as  the 
telephone  industry  did  for  wide  area  telephone  networks. 
The  four  commonly  used  LAN  topologies  are  star,  ring,  bus, 
and  tree. 

1.  Star 


Figure  2.  2  is  an  example  of  how  star  networks 
connect  all  nodes  in  the  network  with  a  point-to-point  link 


Figure  2.  1  Mesh  Topology. 


to  a  common  central  switching  or  processing  node.  This 
structure  is  prevalent  in  wide  area  networks  where  central¬ 
ized  control  is  important.  All  communications  are  set  up 
and  maintained  by  the  central  node  through  which  all  traffic 
must  pass.  This  is  a  natural  extension  of  the  time-shared 
host  computer  configurations.  A  good  example  is  MCDN  where 
front  end  communications  processors  act  as  a  message  switch 
for  the  3270  bi-synchronous  terminals  attached  with  twisted 


Simple  control  structure,  easy  regulation  of  network 
access,  and  similarity  (thus  familiarity)  to  the  time-shared 
systems  are  all  advantages  of  the  star  network.  Central 
processing  places  minimal  burden  on  the  stations  but  by  the 
same  token  makes  the  central  node  more  complex.  A  signifi¬ 
cant  advantage  of  the  star  topology  is  that  it  can  utilize 
the  existing  star-based  telephone  network  cabling  already 
installed.  This  cabling  together  with  a  PBX  or  CBX  that  can 
handle  data  switching  offers  a  relatively  inexpensive  local 
area  network.  Many  integrated  and  dedicated  data  PBX' s  can 
make  immediate  use  of  the  installed  wire  resources  saving 
considerable  cost  on  cable  installation.  If  the  switch  in 
use  cannot  handle  data,  a  significant  investment  is  required 
to  buy  and  install  one  that  does.  The  greatest  disadvantage 
is  total  reliance  on  the  single  central  node  which,  when  it 
fails,  brings  down  the  entire  network.  The  network  is  also 
limited  in  expandability  to  the  maximum  number  of  stations 
the  central  node  can  handle.  Large  volumes  of  traffic  may 
cause  serious  delays  at  the  central  control  point. 

2.  Ring 

A  ring  or  loop  network  (Figure  2.3)  is  a  set  of 
nodes  in  a  closed  loop  of  cable  with  repeaters  connected  on 
either  side  with  point-to-point  circuits  to  two  other 
repeaters.  Messages  are  placed  on  the  ring  in  one  direction 
using  time-division  multiplexing  that  either  assigns  the 
time  slots  permanently  ( slotted  ring)  or  on  demand  ( token 
ring  or  contention  ring).  Control  of  the  time-slots,  which 
in  turn  controls  access  to  the  network,  can  be  centralized 
in  one  node  or  distributed  among  all  the  nodes.  More  infor¬ 
mation  on  access  methods  is  provided  in  the  next  section. 
The  ring  structure  is  often  called  active  because  as 
messages  move  around  the  network,  all  nodes  or  repeaters 
actively  participate.  Each  one  accepts  its  own  messages  and 
passes  on  messages  destined  for  others.  The  biggest 


advantages  of  the  ring  are  ease  of  message  routing,  low 
cost,  and  relatively  easy  expandability.  On  the  negative 
side,  a  single  break  in  the  ring  can  bring  down  the  entire 
network.  Some  vendors  have  defeated  this  problem  by  using 
by-pass  relays  to  eliminate  the  path  through  failed 
repeaters  or  dual  cables  to  by-pass  failed  cable  sections. 
As  the  ring  gets  larger,  the  round  trip  delay  for  the 
message  can  be  a  significant  problem  in  some  control  struc¬ 
tures.  Adding  new  nodes  to  the  ring  is  limited  only  by  the 
maximum  addressing  capability  and  the  maximum  allowable 
physical  distance  between  repeaters. 


Figure  2. 3  Ring  Topology. 


A  bus  is  simply  an  unclosed  two  way  ring/loop 
network  that  does  not  use  active  repeaters  (Figure  2.4). 
Farh  station  has  a  single  unique  address  for  identification 
curing  transmission  and  receipt  of  messages.  The  simple 
passive  interface  gives  the  bus  the  advantages  of  the 
ring/loop  topology  without  the  disadvantage  of  one  failure 
bringing  down  the  network.  All  stations  connect  to  the  main 
transmission  line  or  bus  and  the  transmission  from  any 
station  propagates  the  length  of  the  bus  received  by  all 


stations.  Bus  topologies  are  more  complex  in  terms  of  the 
contention  control  schemes  needed  to  determine  who  transmits 


when.  Control  can  be  centralized  or  decentralized.  When 
centralized,  a  network  rontroller  is  used  to  poll  all  nodes 
or  receive  transmission  requests  then  grant  access  authority 
to  individual  nodes.  When  decentralized,  a  contention 
scheme  is  used  by  all  stations  to  control  network  access. 
The  number  of  allowable  nodes  is  once  again  limited  by  the 
addressing  scheme  and  propagation  delays  associated  with  the 
length  of  the  bus.  Performance  is  determined  by  the  band¬ 
width  of  the  bus,  number  of  nodes,  access  method,  and 
traffic  load. 


Figure  2.4  Bus  Topology. 

The  tree  topology  is  a  form  of  bus  topology  where 
the  medium  is  a  branching  cable  with  no  closed  loops  (Figure 
2.5).  Transmission  from  any  station  propagates  throughout 
the  medium  and  is  received  by  all  others.  Bus  and  tree 
topologies  are  often  called  multi-point  or  broadcast 
[Ref.  8:  p.  56]. 


^  o 


Figure  2.  5  Tree  Topology. 


D.  ACCESS  METHODS 

Use  of  a  shared  local  network  requires  that  any  station 
wanting  to  transmit  must  first  gain  access  to  the  network. 
Different  access  methods  offer  different  characteristics. 
Therefore,  traffic  volumes  plus  time  sensitivity  and 
sequencing  of  the  data  are  characterized  to  determine  which 
method  is  best  suited  for  the  network  to  be  installed.  Once 
a  station  gains  access  to  the  medium,  it  can  either  exhaus¬ 
tively  transmit  all  frames  awaiting  transmission  or  transmit 
only  a  maximum  number  of  frames  per  attempt.  Access  methods 
can  be  centralized,  where  a  central  arbiter  has  control  over 
access  by  the  other  nodes,  or  distributed.  Distributed 
control  allows  individual  user  devices  or  network  interface 
devices  to  control  their  own  access.  Time  division  multiple 
access,  circuit  switching,  and  reservation  are  examples  of 
centralized  access  while  token  passing  and  Carrier  Sense 
Multiple  Access  (CSMA)  are  distributed  examples. 


1.  Inns  Division  Multiple  Access  ( TDm) 

This  method  permits  all  devices  to  share  the  trans¬ 
mission  time  one  at  a  time.  This  is  done  in  a  predetermined 
sequence  or  based  on  need  to  transmit  determined  by  polling 
queries  from  the  central  arbiter.  The  main  idea  is  to  allo¬ 
cate  access  to  the  medium  in  a  deterministic,  equitable 
manner.  MCDN  is  a  good  example  of  this  method  where  the 
front  end  processor  polls  line  devices  for  traffic.  Another 
variation  of  this  method  is  called  slotted  TDMA.  The  avail¬ 
able  time  is  broken  into  time  slots  of  equal  length  which 
are  allocated  to  the  various  devices  on  the  network. 


Devices  only  send  in  their  assigned  slot  and  only  for  the 
duration  of  that  slot.  If  the  message  does  not  fill  the 
slot,  the  unused  portion  goes  empty.  If  it  is  longer  than 
one  slot,  it  is  broken  up  and  sent  over  several  slots.  All 
stations  must  be  able  to  detect  the  beginning  and  end  of 
each  slot  so  synchronization  is  critical. 

The  last  variation  is  called  slotted  ring  which  also 
involves  a  fixed  number  of  slots  of  equal  duration.  All 
slots  are  initially  marked  empty  using  a  status  bit  at  the 
beginning  of  the  frame.  If  a  station  wants  to  transmit,  it 
waits  for  an  empty  frame,  changes  the  status  bit  from  empty 
to  full,  and  inserts  a  frame  of  data  as  the  empty  slot  goes 
by.  Normally,  the  frame  also  contains  two  response  bits 
which  are  changed  by  the  receiving  station  to  indicate 
accepted,  busy,  or  rejected.  The  slot  returns  to  the  source 
and  is  marked  empty  or  refilled  based  on  the  response  bits. 
Other  variations  may  allow  change  of  the  status  bit  by  the 
receiving  station  based  on  successful  receipt  of  the  frame. 

2.  Carrier  Sense  Multiple  Access  ( CSMA ) 

CSMA  is  used  in  networks  with  common  transmission 


media  like  the  bus  and  tree  topologies. 


Each  node  contends 


for  access  or  control  in  a  decentralized  manner. 


In  this 


method  all  devices  must  be  able  to  listen  to  the  network  and 


[•] 


detect  if  other  devices  are  transmitting.  If  a  transmission 
is  in  progress,  then  the  listening  device  will  wait  until 
the  line  is  clear  before  transmitting.  A  second  feature  can 
be  added  to  this  method  called  CSMA  collision  detection 
(CSMA/CD).  During  heavy  traffic  periods,  several  devices 
can  be  waiting  to  transmit,  which  could  cause  a  collision  if 
all  begin  at  the  same  time.  Collision  detection  allows  a 
sending  station  to  listen  while  transmitting  and  if  it 
detects  the  presence  of  another  signal  besides  its  own,  it 
will  stop  transmitting  and  back  off  for  a  random  amount  of 
time  before  trying  again.  Some  systems  also  have  the  trans¬ 
mitting  station  that  detects  the  collision  send  a  jam  signal 
to  ensure  none  of  the  receiving  stations  try  to  interpret 
the  bad  data.  This  also  allows  buffers  holding  any  of  this 
bad  data  to  be  cleared.  The  random  back  off  reduces  the 
statistical  probability  of  a  second  collision  with  the  same 
station.  As  more  devices  attempt  to  transmit  in  a  network 
using  CSMA/CD,  network  efficiency  declines  because  of  the 
increased  time  spent  resolving  collisions.  Mixing  devices 
that  send  long  messages  with  those  that  send  intermittently 
also  increases  the  probability  of  collision.  The  random 
versus  deterministic  properties  of  this  method  offer  excel¬ 
lent  performance  at  low  load  levels.  However,  applications 
which  require  known  transmission  delays  and  guaranteed 
access,  such  as  digitized  voice  or  synchronous  devices,  find 
this  method  unacceptable. 

3 •  Token  Passing 

In  token  passing  systems,  a  unique  sequence  of  bits 
depicting  a  free  token  is  circulated  from  one  node  to 
another  in  a  predetermined  sequence.  If  a  node  has  data  to 
transmit,  it  changes  the  token  bit  sequence  to  indicate  busy 
then  sends  its  traffic.  After  transmission,  the  sending 
node  changes  the  token  bit  sequence  back  to  free  and  sends 
it  on  to  the  next  node  in  the  access  sequence.  The  only 


network  overhead  is  the  token  bit  sequence  which  is  a  fixed 
length  so  maximum  delay  can  be  calculated.  Other  advantages 
include  high  transmission  efficiency  for  varied  packet  sizes 
and  data  rates,  reliable  operation  under  all  load  condi¬ 
tions,  and  freedom  from  collision  detection  requirements. 
Token  loss  or  damage  and  fixed  response  time,  even  during 
light  load  conditions,  are  the  two  biggest  disadvantages. 
Token  loss  or  damage  is  usually  solved  by  using  a  network 
monitor  which  keeps  track  of  the  token's  status.  The 
monitor  may  also  take  on  the  responsibility  for  reconfigura¬ 
tion  of  the  token  passing  sequence  as  stations  enter  and 
leave  the  network. 

E.  PROTOCOLS  AND  STANDARDS 
1.  General 

Exchange  of  information  among  information  systems  is 
a  complicated  process.  The  required  cooperation  must  be 
formalized  in  rules  which  define  the  methods,  procedures, 
and  conventions  needed  to  complete  the  information  exchange. 
These  rules,  called  protocols,  are  the  common  tools  designed 
to  control  information  transfer  between  computer  systems. 
They  are  imbedded  in  specific  elements  of  the  information 
system  and  are  designed  to  effect  the  movement  of  informa¬ 
tion,  ensure  mutual  understanding,  and  to  provide  error 
control  and  recovery  procedures. 

Early  experimental  computer  networks  were  developed 
independently  which  resulted  in  the  creation  of  many 
different  architectures  and  conventions  for  interconnecting 
equipment.  These  differing  approaches  were  often  proprie¬ 
tary  and  generally  incompatible.  The  growth  of  automated 
information  processing,  the  requirement  for  distributed 
elements  to  interoperate,  and  the  cost  inefficiency  of 
dealing  with  incompatible  protocol  architectures  highlighted 
the  need  for  standardization. 


2.  His  QS1  Model 

In  1977,  this  need  for  standardization  was  recog¬ 
nized  by  the  International  Organization  for  Standardization 
(  ISO)  and  a  special  subcommittee  was  created  to  develop  a 
standard  architecture  for  Open  Systems  Interconnection  (OSI) 
[Ref.  9:  p.  425].  The  subcommittee's  objective  was  to 
develop  a  standard  international  standard  open  system  archi¬ 
tecture  which,  if  followed,  would  enable  heterogeneous 
system  interconnection  and  communication.  Early  discussions 
resulted  in  the  agreement  among  subcommittee  members  to 
develop  a  layered  architecture  which  would  break  the 
complexities  of  data  communications  into  manageable 
portions.  A  logical  structured  sequence  of  layers  would  be 
specified,  each  of  which  would  handle  specific  functions. 
They  would  be  designed  independently  however,  each  would 
support  and  interconnect  with  the  layer  above  and  below  it. 
Each  layer  would,  through  the  layers  below  it,  interact  with 
the  corresponding  (peer)  layer  located  in  the  other  informa¬ 
tion  system  elements.  The  subcommittee's  first  1.5  years  of 
work  resulted  in  the  layered  ISO  OSI  reference  model 
( OSI/RM)  (Figure  2.6).  The  outside  boxes  represent  the 
common  layers  at  each  data  terminal  equipment  (DTE)  loca¬ 
tion.  The  center  three  boxes  represent  the  layers  employed 
by  data  circuit-terminating  equipment  (DCE)  when  an  interme¬ 
diate  network  is  used  for  long  distance  transmission  between 
more  than  one  DTE  local  network.  This  layering  approach 
offered  the  following  advantages  taken  from  [Ref.  4:  p. 


5-76] 


Any  given  layer  can  be  modified  or  upgraded  without 
affecting  the  other  layers. 

Modularization  by  means  of  layering  simplifies  the 
overall  design. 

Different  layers  can  be  assigned  to  different  standards 
committees  or  different  design  teams. 

Fundamentally  different  mechanisms  may  be  substituted 
without  affecting  more  than  one  layer  ( e. g. ,  packet 
switching  versus  leased-line  concentrators). 

Different  machines  may  plug  in  at  different  levels. 


The  relationships  between  the  different  control  func¬ 
tions  can  be  better  understood  when  they  are  split  into 
layers.  This  is  especially  true  with  the  control 
actions  which  occur  sequentially  in  time  from  layer  to 
layer. 


•  Common  lower  level  services  may  be  shared  by  different 
higher  level  users. 

•  Functions,  especially  at  lower  layers,  may  be  removed 
from  software  and  built  into  hardware  or  microcode. 

There  are  some  disadvantages.  However,  when  compared  to 

the  advantages,  their  impact  is  slight. 

•  The  total  overhead  is  somewhat  higher. 

•  The  communicating  machines  may  have  to  use  certain 
functions  which  they  could  do  without. 

•  To  make  each  layer  usable  by  itself  there  is  some  small 
duplication  of  function  between  the  layers. 


•  As  technology  changes  ( e. g. ,  as  cryptography  and 
compaction  chips  become  available,  or  these  functions 
can  be  built  onto  chips)  the  functions  may  not  be  in 
the  most  cost-effective  layer. 

A  number  of  principles  were  used  by  the  ISO  subcom¬ 
mittee  to  arrive  at  the  seven  layer  OSI/RM.  Things  like 
minimizing  the  number  of  layers,  creating  boundaries  to 
minimize  the  number  of  interactions  across  them,  collecting 
similar  functions  in  the  same  layer  and  some  10  other  prin¬ 
ciples  were  considered  to  arrive  at  the  specified  functions 
in  each  layer  [  Ref.  9:  p.  4291 .  The  layers  are  often  broken 
into  two  basic  levels:  low-level  protocols  (  levels  1  &  2  in 

the  OSI/RM)  and  high-level  protocols  (levels  3-7).  The 
low-level  protocols  identify  the  basic  conventions  used  to 
transport  the  data  signals  (bits)  through  the  network  in  a 
timely  and  reliable  manner.  There  is  no  real  concern  for 
the  meaning  of  the  bits  being  transmitted.  The  high-level 
protocols,  on  the  other  hand,  transmit  and  interpret  the 
meaning  of  the  bits  and  data  structures  used  to  communicate 
and  support  end  user  applications.  In  a  sense,  the 
low-level  protocols  provide  a  foundation  to  support  the 
high-level  protocols  which  in  turn  support  the  user.  Each 
layer  or  level  uses  functions  provided  through  the  level 
below  them  and  provide  new  or  additional  functions  to  the 


changes  (  e.  g.  ,  as  cr 


levels  above. 


a.  Physical  Layer 

The  physical  layer  is  concerned  with  the  trans¬ 
mission  of  raw  data  over  the  transmission  medium.  It 
provides  the  electrical,  mechanical,  functional,  and 
procedural  characteristics  like  voltages,  connectors, 
frequencies,  modulation,  etc,  used  to  establish,  maintain, 
and  release  physically  connected  data  circuits  between  DTEs. 

b.  Data  Link  Layer 

This  layer  contains  the  control  functions  or 
rules  needed  to  reliably  transfer  data  over  the  communica¬ 
tions  link  established  by  level  1.  The  data  link  rules 
define  initialization  and  synchronization;  control  errorless 
data  interchange  with  addressing,  frame  sequencing,  request 
and  acknowledge,  error  checking,  etc;  terminates  data  trans¬ 
actions;  and  provides  for  recovery  from  abnormal  condi¬ 
tions  like  invalid  or  lost  responses,  loss  of 
synchronization,  and  faults  caused  by  noise,  interference, 
or  failure  of  the  physical  link.  [Ref.  10:  p.  4-15].  These 
protocols  were  originally  character  oriented  to  support  the 
early  synchronous  bulk  data  transfer  requirements.  However, 
because  of  the  high  overhead  involved  for  short  bursty 
transmissions,  which  characterize  the  newer  interactive 
applications,  bit-oriented  protocols  were  developed.  This 
shortened  and  streamlined  data  link  procedures. 

c.  Network  Layer 

The  network  layer  manages  the  routing  of 
messages  from  sender  to  destination  and,  wlien  more  than  one 
path  is  involved,  selects  the  route  that  best  suits  network 
conditions  to  prevent  congestion.  This  layer  relieves  the 
transport  layer  of  responsibilities  for  routing  and 
switching.  Because  of  their  broadcast  nature,  network 
services  are  not  required  when  dealing  with  local  area 
networks.  However,  layer  3  is  vital  to  successful 
communication  between  LANs  or  between  a  LAN  and  a  WAN. 


d.  Transport  Layer 

The  transport  layer  is  the  end-to-end  layer  that 
provides  a  transparent  means  of  transferring  data  for  the 
session  layer  above  it.  It  segments  the  message  into 

manageable  parts  or  packets  sized  to  fit  the  network  being 
used  for  transmission.  At  the  destination,  these  packets 
are  reassembled  and  sent  to  the  destination  session  layer. 

e.  Session  Layer 

This  layer  is  the  user's  interface  to  a  network. 
It  involves  a  set  of  log  on  and  dialog  rules  that 
enable  the  user  to  logically  interconnect  with  various 
remote  hardware/software  locations.  It  essentially 

controls,  delimits,  and  synchronizes  the  data  operations 
between  two  presentation  layers. 

f.  Presentation  Layer 

This  layer  involves  the  management  of  the 
exchange,  display,  and  control  of  the  structured  data  from 
the  applications  layer.  The  applications  layer  selects  the 
set  of  services  like  data  content  architecture,  data  inter¬ 
face  architecture,  data  compression  technique,  encryption, 
etc,  which  enable  it  to  interpret  or  encode  the  data  being 
exchanged.  It  ensures  that  the  information  exchanged 

between  application  layers  is  meaningful. 

g.  Application  Layer 

This  is  the  highest  layer  in  the  OSI/RM  archi¬ 
tecture.  It  directly  serves  the  end  users  through  the  use 
and  interpretation  of  content  (meaning),  semantics,  and 
syntax  involved  in  normal  person-to-person  communications. 
It  involves  the  function  needed  to  initiate,  maintain, 
terminate,  and  record  data  transfer  between  two  applications 
layers. 

3 .  LAN  Standards 


Along  with  the  ISO  subcommittee's  OSI/RM  came  a 
recommendation  to  begin  projects  to  develop  protocols  for 


specific  communications  networks  including  LANs.  LAN  facil¬ 
ities  and  standards  tend  to  cover  only  the  physical  and  data 
link  layers  as  depicted  in  Figure  2. 7  from  [ Ref.  11:  p. 
191] .  However,  some  vendor  software  and  hardware  combina¬ 
tions  may  involve  all  seven  layers  to  permit  interaction 
like  personal  computers  communicating  with  a  host  computer 
at  the  applications  level.  When  a  single  vendor  provides 
this  kind  of  complete  network  services,  he  tends  to  work  out 
interfaces  and  protocols  to  get  the  best  performance  from 
his  own  product.  If  a  system  is  pieced  together  in  this 
manner,  complete  understanding  of  the'  vendor's  interfaces 
and  protocols  is  imperative. 

In  the  absence  of  accepted  standards,  vendors  tend 
to  develop  their  own.  They  hope  that  industry  and  indi¬ 
vidual  buyers  will  rally  around  these  "defacto"  standards  to 
encourage  their  acceptance  at  least  nationally.  This  is 
exactly  the  case  with  LAN  standards.  In  February  1980, 
shortly  after  the  ISO  subcommittee  recommendations  were 
submitted,  Project  Group  802  of  the  IEEE  Computer  Society 
was  set  up  to  develop  LAN  standards.  Three  working  groups 
were  established,  two  to  define  standards  for  the  physical 
and  link  layer  protocols  with  a  third  to  act  as  liaison  with 
higher  network  layer  projects.  This  third  group  was  also 
chartered  to  provide  guidelines  for  the  standards  to  satisfy 
user  needs  with  respect  to  existing  higher  levels, 
inter-network,  and  network  management  issues. 

DEC,  Intel,  and  Xerox  immediately  submitted  detailed 
specifications  for  a  well-known  CSMA/CD,  bus,  coaxial  cable 
system  known  as  ETHERNET.  They  proposed  that  ETHERNET  be 
accepted  as  "the"  LAN  standard.  However,  early  IEEE 
sessions  surfaced  strong  opposition  from  advocates  of  token 
passing,  particularly  Honeywell  and  IBM.  Later  that  year 
the  conflict  was  resolved  by  breaking  working  group  1  into 
subgroups  which  were  directed  to  develop  CSMA/CD  and  token 


Figure  2. 7  Relationship  Between  OSI/RM  and 
LAN  Standards. 


passing  methods  in  parallel.  A  demand  was  also  made  to  make 
all  specifications  identical  except  for  the  algorithm  itself 
(i.e.  addressing,  frame  format,  coding  method,  etc,  ).  The 
subsequent  proposed  changes  to  ETHERNET  from  those 
supporting  token  passing  brought  progress  to  near  stand¬ 
still.  Finally,  the  ISO  decided  to  not  only  include  CSMA/CD 
and  token  passing  as  separate  bus  broadcast  standards  but 
also  to  develop  token  passing  in  a  sequential  topology,  the 
token  ring.  The  current  IEEE  802  committees  have  the 
following  responsibilities  [Ref.  12:  p.  358]: 

•  802. 1  Higher  layer  protocol  liaison 

•  802. 2  Common  logical  link  protocol 

•  802. 3  ETHERNET  or  CSMA/CD  bus  access  method 

•  802. 4  Token  passing  bus  access  method 

•  802. 5  Token  passing  ring  access  method 

•  802. 6  Metropolitan  area  networks 

According  to  Roelandts  [Ref.  13:  p.  231]  ,  802.3  and 
802. 4  standards  have  completed  the  approval  process  and  are 
now  recognized  standards.  802.5  is  still  in  process  and 
manufacturers  are  having  difficulty  implementing  this 
complex  standard  in  silicon.  The  availability  of  network 
controllers  integrated  on  a  chip  brings  down  the  price  and 
raises  the  volume.  This  is  the  normal  ticket  to  success  for 
a  protocol.  However,  the  fact  that  IBM  ( controller  of  65% 
of  the  computer  market)  supports  802.5  may  be  the  ace  in  the 
hole  it  needs  to  survive. 

4.  High  Laver  Protocol  Standards 

The  physical  and  link  layer  protocols  are  very 
important  when  desiring  compatibility  on  a  single  LAN.  This 
is  where  most  LAN  standards  activity  has  been  concentrated. 
However,  standards  at  the  network  layer  and  above  are  crit¬ 
ical  for  compatibility  and  communication  LAN  to  LAN  or  LAN 
to  WAN.  These  are  the  protocols  that  affect  the  user's 

ability  to  do  things  like  access  a  remote  computing  resource 


and  other  users,  transfer  files  from  one  system  to  another, 
or  send  mail  to  other  users  on  the  network. 

Before  LANs,  long  distance  network  protocols  were 
oriented  toward  data  communications  rather  than  networking. 
These  protocols  supported  the  communications  required  by 
terminals  connected  to  a  host  computer  which  in  turn  was 
connected  to  one  or  more  other  hosts  with  their  own  termi¬ 
nals.  The  emergence  of  LANs  generated  a  new  need  for  tying 
together  networks  that  already  had  their  own  network  access 
and  message  transmission  and  reception  protocols. 
Initially,  design  concentrated  on  the  terminals  in  these 
networks.  However,  that  emphasis  has  now  shifted  to 
providing  long-distance  access  to  self-contained  local 
networks  that  have  their  own  protocols  for  communication 
among  the  local  workstations.  This  concept  caused  designers 
to  view  the  local  area  network  as  a  single  terminal  [Ref.  5: 
p.  15-16], 

About  the  same  time  that  LAN  protocols  were  begin¬ 
ning  their  design  and  specification  phase,  long  distance 
public  data  networks  were  growing  rapidly  and  their  proto¬ 
cols  were  relatively  mature.  The  International  Telegraph 
and  Telephone  Consultive  Committee  (CCITT)  had  already 
established  recommended  standard  protocols  for  both  synchro¬ 
nous  circuit  switched  and  asynchronous  packet  switched  data 
networks.  CCITT  X. 21  is  the  general  purpose  interface 
between  data  DTE  and  DCE  elements  for  synchronous  operation 
on  public  data  networks.  CCITT  X. 25  is  the  standard  device¬ 
independent  interface  between  packet  networks  and  user 
devices  operating  in  the  packet  mode.  These  protocols 
concentrate  on  the  first  three  layers  of  the  OSI/RM  for 
DTE/DCE  connection  (Figure  2.6).  Both  are  primarily  network 
layer  protocols  consistent  with  the  OSI  model  for  distribu¬ 
tion  of  functionality  among  layers.  DOD  used  the  OSI  model 
and  packet  switching  features  of  X. 25  to  come  up  with  its 


own  network  model.  This  model  not  only  supports  the  open 
system  model  concept  but  also  incorporates  special  features 
to  enhance  reliability  and  to  support  special  DOD  security 
requirements. 

DOD  began  experimenting  with  the  X.  25  packet 
switching  protocols  during  the  development  and  implementa¬ 
tion  of  the  ARPANET  protocol  suite.  This  work  resulted  in 
the  DOD  INTERNET  model  (not  formally  defined  until  1982) 
which  has  guided  the  implementation  of  many  DOD  protocols 
and  communications  networks  since  the  early  70' s.  This 
model  emphasizes  internetworking  of  computer  systems  through 
communications  subnets  for  host-to-host  communications, 
subnet- to- subnet  communications,  and  resource  sharing.  The 
idea  is  that  each  subnet  has  its  own  set  of  protocols  which 
may  or  may  not  be  the  same.  They  communicate  with  each 
other  through  gateways  to  the  WAN.  This  is  achieved  through 
two  companion  protocols  called  Internet  Protocol  ( IP)  and 
Transmission  Control  Protocol  (TCP)  [Ref.  7:  p.  Ill —46] .  IP 
provides  datagram  service  for  applications  sensitive  to 
fast,  nonsequenced  delivery  across  several  networks.  TCP 
uses  the  services  of  IP  plus  sequenced  delivery,  flow 
control,  and  end-to-end  acknowledgement  to  offer  a  virtual 
circuit  service  for  applications  that  require  interactive 
terminal  to  remote  host  processing.  Figure  2. 8  shows  how 
the  DOD  INTERNET  Model  matches  up  against  the  OSI/RM. 
Problems  with  adoption  of  the  OSI  transport  layer  protocols 
have  been  difficult  to  resolve  because  of  the  existence  of 
both  the  connection-oriented  virtual  circuit  and  the  connec¬ 
tionless  datagram  service.  As  a  result,  five  different 
classes  of  service,  which  provide  varying  degrees  of  reli¬ 
ability,  have  been  established  for  the  OSI  transport  layer. 
This  multi-class  approach  will  have  significant  negative 
effects  on  reliability  of  internetworking  communications. 
It  will  cause  increased  opportunity  for  undetected  errors  or 


lost  messages  due  to  their  different  characteristics.  The 
Defense  Data  Network  (DDN)  TCP/IP  falls  in  the  class  4 
category  which  is  the  most  complex.  Proponents  of  TCP/IP 
are  currently  trying  to  convince  the  major  standards  organi¬ 
zations  to  adopt  them  as  "the"  networking  protocol  standards 
for  long  distance  networks.  They  are  already  mandatory  in 
all  DOD  packet  switching  networks  which  connect  or  have  the 
potential  for  utilizing  connectivity  across  network  or 
subnetwork  boundaries  [Ref.  7:  pp.  1 1 1-46- 1 1 1-48] . 

There  is  a  great  deal  of  discussion  among  DOD 
network  designers  regarding  whether  to  require  TCP/IP  in  LAN 
protocol  design.  Proponents  argue  that  this  would  greatly 
enhance  reliability  and  speed  transmission  through  gateways 
at  the  LAN/WAN  boundary.  They  say  it  would  reduce  the 
costly  complex  functions  of  higher  layer  protocol  transla¬ 
tion  and  mapping.  An  additional  benefit  would  be  increased 
speed  through  the  gateway  due  to  the  decreased  protocol 
translation.  Opponents  argue  that  the  LAN  overhead  costs 
associated  with  such  a  move  are  unnecessary  for  subnets 
whose  communications  and  information  exchange  are  primarily 
local.  Only  significant  testing  and  modelling  will 
determine  whose  argument  is  correct. 

F.  PBX  TECHNOLOGY 

The  logical  and  insistent  move  from  analog  to  digital 
transmission  techniques  has  precipitated  an  evolutionary 
change  in  telephone  switching  equipment.  Early  first  gener¬ 
ation  step-by-step  mechanical  private  branch  exchange  (PBX) 
telephone  switches  were  replaced  by  second  generation  elec¬ 
tromechanical  common  control  devices.  This  happened  when 
the  telephone  industry  borrowed  stored-program  control  from 
the  computer  industry.  Recognizing  the  growing  need  to 
switch  data  as  well  as  voice,  third  generation  PBX's  were 
developed  to  digitize  voice  signals  either  at  the  telephone 
instrument  or  through  a  line  card  at  the  PBX.  Voice  and 
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data  terminals  can  now  access  the  switching  equipment  on  the 
same  line.  This  not  only  enables  voice  and  data  to  use  the 
same  medium  and  transmission  equipment  but  also  facilitates 
transmission  between  switching  nodes  by  multiplexing  both 
signals  with  TDM  techniques.  Since  the  system  uses  the  same 
twisted-wire  telephone  cable  for  voice,  data,  and  control 
signals,  it  is  a  cost  effective  way  to  satisfy  both  voice 
and  data  switching  requirements.  It  is  important  to  recog¬ 
nize  that  the  third  generation  switch  technology  reflects 
the  prevailing  concern  of  the  middle  and  late  70 's  which  was 
digitized  voice.  They  treat  data  as  an  add-on  capability 
which  is  normal  because  voice  telephone  calls  are  still  the 
main  source  of  business.  This  step  child  treatment  results 
in  relatively  slow  transmission  rates:  19.2  kbps  for 
asynchronous  RS-232C  data  interfaces  and  up  to  64  kbps  for 
synchronous  data  interfaces.  A  limited  protocol  conversion 
capability  for  asynchronous  data  packetizing  functions  is 
provided  on  some  vendor  offerings.  These  rates  may  satisfy 
the  needs  of  many  office  automation  requirements  but  come 
nowhere  close  to  LAN  speeds  offered  for  mainframe  access, 
file  transfer,  program  sharing,  and  micro-to-micro  communi¬ 
cation.  These  switches  were  not  designed  for  high-speed 
packet  switching.  Many  data  switching  network  buyers  are 
looking  for  a  better  solution  than  using  existing  PBX  assets 
for  voice  and  low  speed  data  transmission  and  then  adding  a 
second  parallel  network  to  handle  high  speed  data  communica¬ 
tions.  The  maintenance  and  expansion  of  multiple  networks 
can  prove  to  be  costly  and  highly  inefficient.  The  recent 
fourth-generation  PBX  products  take  the  digital  switching 
technology  a  step  beyond  voice/data  integration  into  a  world 
of  enhanced  networking  capabilities. 

Fourth-generation  PBX  ( often  called  CBX)  systems  combine 
advanced  voice  communication  features,  high  speed  data 
transmissions,  and  integrated  LAN  capabilities.  Such 


systems  could  potentially  meet  all  needs  in  one  integrated 
network  which  would  allow  sharing  of  valuable  resources  as 
well  as  consolidation  of  network  management  facilities. 
According  to  Jewett  [Ref.  14:  p.  47a] ,  the  following  five 
major  capabilities  differentiate  a  fourth  generation  PBX 
from  the  third  generation. 

•  The  fourth-generation  PBX  includes  an  integrated  LAN 
that  is  intrinsically  part  of  the  PBX  architecture, 
thus  providing  the  potential  for  fully  integrated  wide¬ 
band  data  transmission  as  well  as  voice  and  message 
communications. 

•  The  dynamic  allocation  of  bandwidth  depending  on  the 
size  and  nature  of  each  transmission.  This  is  the 
principal  technology  advance  that  sets  it  apart  from 
third  generation.  Dynamic  bandwidth  allocation  allows 
the  system  to  grow  as  user  requirements  grow  which 
should  enable  accommodation  of  many  future  wideband 
demands. 

•  The  ability  to  integrate  a  oacket  channel  to  each 

terminal  in  the  system  -  a  packet  channel  that  is 

accessible  by  the  user  s  data  terminal  equipment.  This 
allows  the  system  to  handle  data  in  an  efficient 
manner,  in  packetized  form,  from  originator  all  the  way 
to  a  local  computer/file  server  or  through  a  WAN  to 
other  host  computers. 

•  Offers  a  layered  software  structure  ( like  a  minicom¬ 
puter)  that  provides  for  the  integration  of  message 

communications  at  every  level.  Technically,  this 
allows  the  linking  of  text  messaging  with  active  call 
processing  which  allows  the  use  of  mail  boxes  and  auto¬ 
matic  call  return  with  the  touch  of  a  single  button. 
The  system  offers  an  easy  to  use  message  telephone  that 
tells  the  user  what  to  do  with  the  touch  of  one  button. 

•  The  system  is  fully  distributed.  The  PBX  nodes  can  be 
spread  over  wide  geographic  boundaries  while  continuing 
to  provide  fully  transparent  communication  with  other 
nodes  on  the  system.  In  addition,  each  node  can  func¬ 
tion  as  a  stand-alone  PBX.  The  network  manager  has  the 
choice  of  distributing  nodes  throughout  the  area  to  be 
serviced  or  placing  all  nodes  in  one  room  like 
traditional  PBX  facilities. 

Although  these  new  fourth-generation  switches  offer  many 
new  technological  advantages,  traditional  star  topology 
disadvantages  like  central  point  of  failure,  central  node 
complexity  and  along  with  it  high  cost,  etc,  still  exist. 
Characterization  of  current  and  future  user  needs  as  well  as 
inter-networking  requirements  and  standardization  will 
likely  determine  whether  this  is  a  viable  networking 
alternative. 


III.  A 


FOR  LM 


A,  GENERAL 

Today's  environment  for  the  LAN  system  designer  is  much 
like  that  depicted  in  Figure  3. 1:  Where  does  one  begin? 
The  early  80' s  approach  to  solving  this  problem  is  a 
bottom-up  design.  With  this  approach  the  customer  buys 
workstations  assuming  that  a  system  exists  that  will  eventu¬ 
ally  allow  him  to  connect  these  workstations  together  and  do 
something  meaningful.  A  common  myth  that  fuels  this 
approach  is  that  communications  networks  like  LANs  can 
interface  with  a  variety  of  other  heterogeneous  networking 
techniques  such  as  X. 25,  SNA,  etc,  using  asynchronous, 
synchronous,  serial,  and  parallel  interfaces.  Another  myth 
is  that  buying  a  network  is  as  easy  as  calling  a  networking 
specialist,  having  him  install  his  product,  then  just  plug 
in  the  the  workstations  and  the  system  works.  These  two 
myths  along  with  the  confusing  vendor  claims  of  universal 
interconnection  and  communications  solutions  have  driven 
users  to  choose  and  install  what  appears  to  be  the  latest 
technology.  They  choose  the  system  with  the  highest  band¬ 
width,  the  largest  number  of  devices,  and  multiple 
information  types.  In  other  words,  the  network  was  speci¬ 
fied  and  chosen  based  solely  on  the  technical  specification 
of  one  networking  solution-- the  LAN.  Because  the  network 
was  essentially  specified  by  the  vendor's  description  of 
what  it  could  do  vice  the  user's  detailed  description  of 
what  was  needed,  these  networks  have  few  problems  passing 
operational  acceptance  criteria.  It  is  only  after  network 
installation  and  acceptance  that  the  organizations  discover 
that  there  were  other  issues  which  should  have  been  resolved 
prior  to  or  during  the  LAN  specification/selection  process. 


LANs  suffer  the  same  fate  as  numerous  previous  network 
designs.  The  subnetwork  (LAN)  is  designed  first  by  network 
specialists  based  on  low-level  technical  and  logical 
performance  criteria  with  high-level  services  and  functions 
designed  later,  again  by  network  specialists.  The  end 
user's  needs  are  a  low  priority  in  this  process.  It  usually 
takes  years  of  coordination  between  user  and  designer  to 
"modify"  the  original  design  to  arrive  at  acceptable  high 
level  services  and  protocols  to  support  them. 

A  more  appropriate  strategy  is  one  that  adopts  a  system 
versus  component  approach  looking  at  things  from  the  top 
down  rather  than  the  bottom  up.  A  close  partnership  between 
users  and  information  system  professionals  is  essential. 
You  need  to  characterize  the  applications  or  end  user 
requirements  to  be  supported,  the  interconnection  and  commu¬ 
nications  services  required  by  user  applications,  and  the 
technology  available  to  support  these  requirements  in  that 
order.  This  should  be  done  first  from  a  functional,  not 
necessarily  technical  standpoint.  Obviously  technical  terms 
are  often  necessary  to  describe  the  application,  but  the 
emphasis  here  is  on  the  need  not  the  solution.  Mistakenly, 
people  often  say  they  have  a  requirement  for  a  LAN.  A  LAN 
is  not  a  requirement  but  rather  an  element  in  a  list  of 
potential  solutions  for  satisfying  an  information  processing 
and  transfer  requirement.  Once  the  user's  need  has  been 
properly  characterized,  a  layered  system  design  approach 
concentrating  on  connections  between  layers  to  optimize 
performance  and  functionality  can  begin.  Figure  3.2  depicts 
the  sequence  that  will  be  used  in  this  chapter  for 
specifying  and  in  the  next  chapter  for  selecting  a  LAN. 

B.  USER  REQUIREMENTS 

The  first  step  in  this  process  is  characterization  of 
the  users  which  leads  to  characterization  of  their 
information  transfer  needs.  An  identification  of  the 
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Figure  3. 2  LAN  Specification/Selection  Strategy. 
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mission  and  functional  responsibilities  to  accomplish  this 
mission  is  the  best  point  of  departure.  Taking  these  func¬ 
tional  responsibilities  to  the  lowest  level  of  detail  will 
permit  subsequent  translation  into  protocol  groupings 
(application,  presentation,  session,  transport  layers). 
This  grouping  will  identify  unique  protocol  requirements  as 
well  as  common  services  shared  by  many  functional  require¬ 
ments.  Labor  and  paper  intensive  procedures  should  be  elim¬ 
inated  or  reduced  by  automated  tools  where  affordable 
productivity  gains  can  be  achieved. 

Once  a  concise  complete  list  of  functional  responsibili¬ 
ties  is  compiled,  the  current  organizational  and  operational 
management  structure  can  be  drawn  depicting  how  these 
mission  functions  are  handled.  Adding  the  information 
sources  and  current  data  flow  techniques  used  to  connect 
information  sources  and  functions  in  the  existing  management 
structure  will  facilitate  identification  of  information 
transfer  deficiencies  as  well  as  connectivity  and  capabili¬ 
ties  that  already  exist.  While  the  objective  is  to 
eliminate  obsolete  end-user  technology,  a  certain  degree  of 
current  system  upgrade  or  perhaps  total  accommodation  of 
existing  equipment/network  procedures  and  interfaces  will  be 
appropriate.  Known  ongoing  system  upgrades  and  improvements 
( i. e.  new  telephone  switches,  cable  plant  improvements, 
recently  acquired  intelligent  workstations,  etc,)  should  be 
addressed  when  identifying  deficiencies.  Separate  explicit 
and  comprehensive  individual  deficiency  descriptions  in 
terms  of  functional  requirements  will  allow  accurate  evalua¬ 
tion  of  their  scope.  Users  must  first  understand  their 
underlying  information  needs  without  regard  for  the  specific 
solution  that  will  be  used  to  satisfy  these  needs.  New 
emphasis  is  needed  to  ensure  that  users  understand  these 
needs  well  enough  to  completely  and  accurately  define  them 
for  the  network  designer.  This  way  the  designer  fully 


understands  the  necessary  information  flows  both  vertical 
and  horizontal.  Identification  of  capabilities  that  already 
exist  will  alert  the  network  designer  and  specification 
preparer  to  required  ( at  this  point)  logical  information 
interfaces  that  must  be  satisfied. 

Identification  of  the  ultimate  source  of  the  information 
and  all  handling  points  in  between  may  allow  the  secondary 
benefit  of  eliminating  those  points  whose  only  function  is 
distribution.  The  degree  of  resource  clustering  to  support 
applications  along  with  the  identification  of  distributed 
versus  centralized  processing  are  additional  off-shoots  of 
this  analysis  process.  Individual  information  systems  are 
seldom  truly  autonomous  units  because  often  the  same  infor¬ 
mation  must  be  moved  from  one  system  to  another.  This 
creates  a  need  for  interoperability  or  sharing.  By  making 
this  kind  of  comparison  and  developing  these  relationships, 
the  individual  systems  become  part  of  a  broader  framework  of 
systems  thus  depicting  an  architecture  of  local  user  needs. 

Several  different  manual  as  well  as  automated  methods  of 
requirements  analysis  exist  for  defining,  developing,  or 
improving  information  systems.  Activity  studies,  review  of 
local  directives  detailing  required  information  submissions, 
and  questionaires  can  all  be  used  in  quantitative  ( linear 
programming)  and  qualitative  studies  for  requirements  iden¬ 
tification  and  analysis.  The  result  should  be  a  priority 
list  of  different  information  subsystems  broken  into  func¬ 
tional  areas  across  command  and  staff  channels.  The  next 
step  is  to  design  equipment  independent  data/voice  system 
solutions  to  satisfy  the  specified  information  subsystem 
requirements. 

Devices  currently  installed  in  most  user  work  areas  are 
not  compatible  because  they  evolved  from  programs  designed 
to  satisfy  differing  requirements.  However,  these  devices 
are  now  crossing  over  many  traditional  boundaries. 


Telephone  systems  now  include  features  that  border  on  data 
processing,  data  processing  includes  office  automation  which 
crosses  into  traditional  administrative  services,  and  small 
computers  sometimes  give  users  more  powerful  software  tools 
than  available  in  large  scale  data  processing  systems.  The 
objective  of  any  user  requirements  study  should  be  the  iden¬ 
tification  of  needs  in  a  way  that  permits  adoption  of  a 
flexible  and  dynamic  open-ended  information  handling  system. 
This  type  of  system  integrates  all  the  technologies  of  data 
manipulation,  text  processing  and  communications.  The  ulti¬ 
mate  goal  may  be  multi-function  workstations  that  offer  a 
wide  range  of  information  handling  tools.  These  work¬ 
stations  could  provide  the  user  with  an  easily  understood 
information  system  interface  which  is  common  among  indi¬ 
vidual  applications.  Moving  information  between  applica¬ 
tions  without  labor  intensive  intermediate  handling  or 
reformatting  in  a  manner  that  supports  the  way  people  really 
work  and  think  will  be  the  key  to  success  in  this 
environment. 

A  poorly  designed  and  managed  information  system  is  just 
as  big  a  contributor  to  the  problems  generated  by  isolated 
individual  information  processing  as  the  standalone  personal 
computers.  Significant  changes  in  operating  procedures,  no 
matter  how  well  intended,  can  cause  severe  problems  with 
user  performance.  Examples  of  the  problems  caused  are:  1)  A 
breakdown  of  the  standard  organizational  information  flow 
and  processing  procedures.  This  can  easily  lead  to  a 
proliferation  of  unique  procedures  for  handling  different 
kinds  of  data  among  people  and  groups  in  the  organization. 
2)  The  organization  loses  control  of  its  information 
resources.  Since  information  is  an  organization's  most 
important  resource,  isolating  and  thus  fragmenting 
processing  and  storage  resources  can  lead  to  an  inability  to 
allocate  them  for  the  benefit  of  the  whole.  3)  Security  and 


integrity  of  data  are  lost.  Intelligent  workstations 
operating  in  isolation  are  still  powerful  tools  for  manipu¬ 
lating  data.  However,  it  is  quite  easy  for  individual  users 
to  change  or  lose  data  without  realizing  it.  4)  Disruption 
of  established  work  flows  that  support  the  organization's 
mission  functions  and  operations.  [Ref.  15:  p.  258]. 

As  individuals  or  individual  parts  of  the  organization 
become  more  productive,  it  affects  everyone  else  whose  work 
is  connected  to  them.  Adequate  planning  and  preparation  is 
essential  to  address  changes  in  work  responsibilities  and 
behavior  patterns,  accommodate  user  concerns,  and  allow 
smooth  transition  to  the  new  capabilities.  By  looking  at 
all  these  factors  in  depth,  an  information  system  architec¬ 
ture  supported  by  one  or  more  processing  and  networking 
strategies  can  be  developed.  The  solution  is  not  known 
before  or  during  the  analysis  so  the  results  should  not  be 
slanted  toward  a  particular  technological  solution.  A 

final  goal  is  to  perhaps  develop  standards  and  guidelines 
which  ensure  individual  projects/programs  maintain  overall 
compatibility  in  specification  and  selection  as  well  as 
installation,  operation,  and  maintenance. 

The  following  is  an  example  list  (certainly  not  exhaus¬ 
tive)  of  broad  functional  categories  that  could  evolve  from 
this  analysis: 

•  Message  and  document  filing,  retrieval,  distribution, 
creation,  and  revision. 

•  Job  entry  on  a  host  or  mainframe 

•  Interactive  terminal  operations  with  a  host  or  another 
terminal 

•  Resource  allocation 

•  Program- to-program  operations  user-user,  user-host, 
etc. 


Artificial  intelligence/expert  systems 
Computer  aided  design  and  engineering  (CAD/CAE) 
Voice  transmission  in  a  distributed  environment. 


Each  of  these  broad  functional  categories  can  then  be  broken 
into  subfunctions  which  state  more  specifically  the  user's 
needs.  For  example.  Table  II  shows  the  subfunctions  for  the 
message  and  document  category.  Subfunctions  in  this  kind  of 
detail  for  each  major  functional  area  ensure  that  no 
subfunctions  necessary  to  accomplish  the  mission  are  omitted 
when  selecting  the  appropriate  technology.  The  next  step  is 
to  take  these  functional  categories  and  translate  them  into 
higher-level  services. 

C.  HIGHER-LEVEL  SERVICES 

This  is  where  we  begin  the  process  of  identifying  the 
specific  technology  best  suited  to  satisfy  all  the  functions 
and  subfunctions  listed  in  the  analysis  above.  Data,  voice, 
video,  and  imagery  are  all  examples  of  information  formats 
that  can  be  processed  and  transmitted  through  a  network. 
The  form  of  the  information  as  well  as  the  ability  to  change 
from  one  form  to  another  without  reducing  integrity  or 
content  should  be  considered  equally  with  the  information 
source  and  the  destination.  Can  it  be  processed  and  passed 
in  an  equal  priority  connectionless  manner  or  is  a  highly 
interactive  dedicated  connection  environment  the  only 
feasible  solution?  This  is  one  of  many  questions  to  be 
asked  when  translating  from  user  requirement  functions  to 
applications.  These  applications  must  be  further  translated 
into  services  and  protocols  designed  to  support  the  require¬ 


ments. 


Characterization  in  this  manner  will  facilitate 


future  tradeoff  decisions  on  multiple  information  types 
versus  handling  characteristics  (  speed,  time-of-service, 
etc,)  for  any  one  type. 

Numerous  software  and  hardware  tools  used  to  satisfy  the 
users  insatiable  desire  for  information  have  led  to  the 
development  of  services  common  to  many  different  applica¬ 
tions.  Database  management,  office  automation,  digitized 
voice,  and  higher-order  languages  for  end-user  software 


TABLE  II 

MESSAGE  AND  DOCUMENT  HANDLING  SUBFUNCTIONS 


1.  Messages 

a)  Ability  to  transmit  information  messages 

b)  Ability  to  store,  distribute  messages 

2.  Information  Filing  and  Retrieval 

a)  Centralized  filing  with  multiple-user  access 

b)  Multiple  level  storage  (diskette,  central  unit, 
host) 

c)  Authorization  levels  (view  only,  view  and  orint, 
print  only,  edit,  edit  and  orint,  private  (no 
access) 

d)  Versatile  indexing 

e)  Purging  capability 

f )  Sufficient  capacity  for  storage  (  growth) 

g)  File  maintenance  (add  to,  delete,  change) 

h)  Immediate  automatic  filing 

3.  Information  Distribution 

a)  Electronic  transmission  of  documents  and  messages 

b)  Ability  to  browse  index  of  mail  box 

c)  Automatic  standard  distribution  lists 

d)  Acknowledgement  of  receipt/deii very 

e)  Access  authorization  for  mail  box  use 

f)  Annotate  documents,  redistribute,  file  purge 

g)  Priority  document  indication 

4.  Information  Creation  and  Revision 

a)  Soohi sticated  editing  functions  (  spelling  check, 
deletion,  move  paragraphs,  reformat',  etc...) 

b)  Merge  caoability  (generation  of  reDetitive 
letters,  text  and  files,  text  and  data) 

c)  Ability  to  electronically  store/retain  what  is 
created 

d)  Retrieve  for  document  creation  (boilerplate, 
standard  paragraphs,  etc...  ) 

e)  Quality  orint  caoability  (versatility  in  type 
styles,  formatting) 

f)  Sufficient  integration  to  allow  for  segmented 
creation  and  revision 

g)  Automatic  generation  of  charts,  graphs 

h)  Mathematical  capabilities 

i)  Creation  and  maintenance  of  file  information 
currently  on  lists 

j)  Simultaneous  input/output 


development  are  all  examples  of  services  supported  by 
today's  technology.  These  services  depend  on  software 
oriented  applications  like  file  transfer,  virtual  terminal, 
terminal  emulation,  and  job  transfer  and  manipulation  to 
accomplish  the  needed  operations.  The  set  of  functions  from 
user  requirements  can  now  be  grouped  and  treated  as  an 
application  or  multiple  applications.  Although  grouped  for 
purposes  of  identifying  common  applications  and  services, 
the  identity  of  individual  functions  and  subfunctions  must 
be  preserved  for  future  development  of  specifications  as 
well  as  test  and  evaluation  objectives  and  procedures.  They 
will  be  the  heart  of  specifications  used  to  solicit  bids 
from  potential  vendors  and  later  as  the  basis  for  test 
criteria  against  which  the  installed  system  can  be  measured. 

Various  information  systems  use  applications  processes 
or  logical  elements  to  perform  the  services  required  by  a 
specific  application.  These  processes  or  protocols  were 
discussed  in  Chapter  2  when  the  OSI/RM  was  explained.  As 
stated  before,  the  OSI/RM  establishes  a  framework  for  func¬ 
tion  standardization  within  protocol  layers  to  facilitate 
modular  protocol  design.  There  is  also  some  hope  that  the 
application  specific  services  within  the  individual  layers 
could  some  day  be  standardized.  As  an  exam1  le,  the 
International  Standards  Organization  (ISO),  is  currently 
working  on  a  file  transfer,  access,  and  management  (FTAM) 
OSI  File  Service  called  Virtual  Filestore.  The  objective  of 
this  work  by  the  ISO  is  to  define  standards  for  transfer¬ 
ring,  accessing,  and  managing  information  stored  in  or  moved 
between  open  systems  as  files.  File  attributes,  file  struc¬ 
tures,  and  file  operations  are  all  listed  and  defined  to 
provide  a  common  model  for  file  transfer  on  all  systems. 
[Ref.  16:  pp.  1414-1419].  Given  the  normal  competition 
among  various  software,  hardware,  and  network  vendors,  stan¬ 
dardization  at  this  level  may  well  be  an  unrealistic  goal. 


However,  standardization  is  certainly  a  better  interoper¬ 
ability  solution  than  the  multi-vendor,  heterogeneous,  non 
interoperable  file  storage  solutions  we  have  now.  Some 
standard  services  and  procedures  must  be  established  to 
allow  peer  communications  between  the  applications  of  two 
stations  desiring  to  exchange  information.  This  is  the 
discourse  that  must  be  used  to  identify  the  services 
required  for  the  application  specified.  File  storage  and 
retrieval,  for  instance,  is  not  just  the  simple  transmission 
of  a  serial  bit  stream  to  a  given  storage  device  then  later 
reconnection  to  the  same  device  to  retrieve  the  same  stream. 
Additional  attributes  like  the  file  name,  file  protection, 
accounting  information,  etc,  must  also  be  stored  and 
retrieved.  A  list  of  the  files  stored,  the  ability  to 
delete  or  rename  files,  and  moving  files  from  one  storage 
location  to  another  are  all  examples  of  the  many  services 
used  when  storing  or  retrieving  files.  Based  on  the  appli¬ 
cation,  higher  level  protocols  must  select  the  services 
required  ,  provide  information  needed  by  them,  report  errors 
in  any  of  the  interrelated  processes  as  well  as  simply 
transmitting  the  data  in  the  file.  [Ref.  17:  p.  1371]. 

Determining  the  services  required  by  the  user  functional 
applications  is  not  relegated  just  to  the  applications  layer 
in  the  OSI/RM.  Actually,  the  top  four  layers  (application, 
presentation,  session,  and  transport)  all  provide  services 
(as  described  in  Chapter  2)  for  every  user  application. 
According  to  Bartoli  [ Ref.  18:  p.  196]  these  services  can  be 
common  to  multiple  applications,  application  specific,  or 
user  specific.  The  common  services,  as  you  would  expect, 
are  used  for  information  transfer  by  many  applications 
regardless  of  their  nature.  Examples  are  set  up  and  termi¬ 
nation.  Specific  service  elements  satisfy  the  special  needs 
of  broad  utility  categories  like  file  transfer,  database 
access,  job  transfer,  etc.  User  specific  elements  satisfy 


particular  user  operations  like  word  processing,  computer 
aided  design,  etc.  As  the  application  progresses  down  the 
OSI/RM  layers,  more  common  and  less  specific  services  should 
exist.  However,  as  we  shall  see  in  the  interconnection 
section,  multiple  local  and  lonq  distance  network  communica¬ 
tions  applications  are  the  source  of  more  special  services. 
This  increases  protocol  complexity  in  the  lower  layers  of 
the  OSI/RM.  When  compiled,  the  collection  of  all  common  and 
specific  services  required  by  the  user  functional  require¬ 
ments  derived  earlier  is  used  to  design  and  develop  the 
protocols  for  the  higher  layers  of  the  OSI/RM. 

D.  HIGHER-LEVEL  PROTOCOLS 

Once  the  necessary  services  have  been  determined,  how 
are  the  protocols  that  support  these  services  created?  USMC 
programmers  and  engineers  will  not  likely  be  writing  proto¬ 
cols  that  support  user  applications  or  communications 
interfaces.  However,  we  must  develop  expertise  to  evaluate 
vendor  and  standard  protocols  designed  to  support  the 
services  required  by  our  users.  Some  sort  of  metliod  is 
needed  which  enables  those  responsible  for  designing  or 
evaluating  large  computer-based  systems  to  determine  exactly 
where  certain  specific  protocol  services  fit  within  the 
general  OSI/RM  and  whether  they  fit  our  needs.  Our  program¬ 
mers  are  normally  experts  in  specific  subfunctions  with 
limited  knowledge  of  communications.  This  is  true  because 
defining  interfaces  between  distributed  software  components 
takes  more  knowledge  of  the  information  to  be  exchanged  than 
the  media  over  which  it  travels.  Reference  manuals  on  what 
was  done  in  the  past  are  the  common  tool  used  by  the  system 
engineer  to  determine  interface  requirements.  Bowers 
[Ref.  19:  p.  479-487]  describes  a  technique  used  by  NASA 
which  may  be  a  better  idea.  This  checklist  technique  iden¬ 
tifies  engineering  considerations  for  interconnecting  system 
modules  on  an  electrical  interface.  This  technique  would 


also  be  very  useful  for  considering  logical  interfaces 
across  protocol  layer  boundaries.  The  checklist  is  used  as 
a  guide  to  ensure  that  functions  are  not  omitted  and 
requirements  are  not  underestimated.  The  following  quote 
from  [  Ref.  19:  pp.  479-480]  describes  the  system  for  which 
this  checklist  technique  was  originally  designed: 


This  system  has  several  important  characteristics. 
First,  it  is  a  large  system  managed  by  a  number  of 
organizational  elements;  second,  it  is  very  complex, 
comprising  many  elements  with  many  interfaces:  third,  it 
is  a  distributed  system,  both  geographically  and  in 
space;  and  fourth,  it  must  be  capable  of  evolutionary, 
modular  growth,  since  replacement  of  the  total  system, 
whether  to  meet  new  requirements  or  to  accommodate  new 
technology,  would  be  too  expensive  to  contemplate. 
Clearly,  some  systematic  approach  is  needed  to 
adequately  describe  and  document  such  a  system. 


This  certainly  fits  the  overall  system  architecture  we  are 
trying  to  design  and  evaluate.  LANs  are  but  one  element, 
however,  this  kind  of  systematic  approach  will  ensure  that 
the  LAN  or  any  other  technology  chosen  fits  the  needed 
services.  Tables  III-VI  show  the  sequence  of  detail  used  by 
the  NASA  engineers  to  support  and  amplify  the  OSI/RM  for 
their  services  and  protocol  applications. 

The  article  indicates  that  a  great  deal  of  research  was 
done  to  characterize  NASA' s  needs  as  well  as  those  of  the 
general  communications  community.  However,  the  work  recom¬ 
mended  by  the  first  two  sections  of  this  chapter  should 
provide  the  information  needed  to  generate  the  USMC  network 
specific  tables.  The  ultimate  objective  here  is  to  ensure 
user  requirements  are  broken  into  a  set  of  services  defined 
more  rigorously  as  they  move  down  the  protocol  layers. 
Starting  at  the  Application  Level  will  ensure  that  each 
successive  lower  level  protocol  preserves  the  special  char¬ 
acteristics  of  the  higher  level.  It  also  makes  sure  that  no 
lower-level  services  required  by  the  higher-levels  are 
omitted.  The  protocols  in  each  layer  can  be  viewed  as 


TABLE  III 


TABLE  V 

APPLICATIONS  LAYER  CHECKLIST 


Security  Identify  logon  and  password  requirements  for: 

a  l  Ac  ecu  (o  the  net  wont 

t> I  Access  to  a  remote  host  on  (he  network 

•  Identify  multilevel  security  requirements  and  procedures  tor  partitioning  ot  resource  acceu  based  on  security  ,c»el  and 
passwords 

•  Identify  methods  tor  initially  entering  logon  ID  jnu  password  mto  system  tables  and  means  tor  changing  these  entries 
bv  user  and  ov  svsiem  administrator 

•  Identity  means  tor  reporting  multiple  attempts  to  enter  passwords 

•  Identify  procedures  tor  terminating  .onneuions  that  .innoi  sanity  password  wi.hm  reasonable  number  of  :nes. 

Cost  Accounting 

•  Con-account  per  connection  tor  host  and  network  separately 

•  Ability  to  change  cost-accounts  within  a  connection  penod 

•  Verification  of  valid  cost-account  and  perrmaion  to  use  cost-account 

•  Reporting  of  cost-account  use 

Priority 

•  Priority  or  queue  position,  bandwidth  allocation,  .minimum  delay  m  use  of  network  services,  and  ability  to  specify 
priority  for  host  services. 

Scheduling. 

•  Identify  means  for  scheduling  of  host  services,  network  routing,  bandwidth,  delay  requirements,  pnonty.  security  level 
during  transmission,  pnyucai  devices  on  hosts  in  support  of  application,  and  application  program  use. 

Address  Management 

•  Application  layer  address  a  its  legal  cost  account,  logon  ID,  and  password  m  each  node  or  host. 

Connection  Establishment,  Release.  Abort: 

•  Establishment  requirements  based  on  logon  ID.  password,  cost  account,  application  program  access  password,  and 
filets i  access  password. 

•  Release  at  normal  program  termination  or  programs  error  termination. 

•  Abort  from  programs  at  end  or  on  receipt  of  manual  abort  signal  from  user. 

Expedited  Data: 

•  Ability  of  application  program  to  generate  a  message  having  expedited  pnonty. 

Peer-to-Peer  Layer  Coordination: 

•  Coordination  to  ensure  that  sending  and  receiving  devices  and  programi  are  available  to  send  and  receive  data. 

•  Ail  fifes  are  open  and  on-line  and  afl  supporting  dences  are  operational  and  property  attached  to  required  programs. 

•  Sufficient  CPU.  RAM.  and  other  resources  have  been  allocated. 

•  Any  special  parameter  settings  of  the  operating  system  or  the  application  program  have  been  made. 

Communications  Mode: 

•  Identification  of  interactive  or  batch  requirement  and  initiation  of  programs  in  proper  mode. 

•  Identification  of  any  security  requirements  for  encryption  of  fields  and  files  or  during  actual  transmission. 

Qualify  of  Service: 

•  Identification  of  specific  generic  parameters  that  can  be  employed  by  ihc  Presentation  layer  to  define  bit-error  rates, 
delay,  lost  data,  restarts,  bandwidth,  and  enor  reporting  requirements. 

Format  Transformation: 

•  Hardcopy  and  sottcopy  format  ®vmg  physical  location  of  data  fields,  field  sues  in  lines  and  characters,  color,  shading, 
line  drawing  characteristics,  font  types,  font  sizes,  hardcopy  physical  dimensions,  interactive  operator  control  fields 
(touch,  lightpen.  trackball,  function  key )  relationships. 

Semantics: 

•  Cause  and  effect  relationships  for  interactive  operations,  error  conditions  m  terms  ot  programs  to  he  minuted  or 
services  to  be  requested. 


individual  data  units  meaningful  in  the  layer  to  which  they 
apply.  Figure  3. 3  [ Ref.  20:  p.  391]  shows  this  relationship 
as  it  applies  to  the  OSI/RM.  The  input  generated  by  the 
user  represents  a  set  of  instructions  that  must  be  packaged 
in  one  or  more  data  elements  and  sent  to  another  user  or 
application.  The  application  layer  appends  a  header  to 
accomplish  the  layer  7  encapsulation  and  passes  the  original 
user  data  plus  the  header  to  the  presentation  layer.  At  the 
presentation  layer  it  is  either  preserved  in  its  original 
data  element  size  or  broken  into  smaller  elements  each  with 
its  own  presentation  layer  header.  These  headers  will  be 
used  at  the  destination  for  regenerating  the  original  appli¬ 
cation  layer  data  elements.  This  process  of  data  element 
plus  layer  unique  headers  continues  down  to  the  data  link 
layer  where  the  data  elements  are  broken  into  frames  and 
receive  a  header  and  trailer  for  transmission  through  the 
physical  medium.  When  the  frames  reach  the  destination,  the 
process  is  reversed.  The  header  information  is  stripped  off 
as  the  data  elements  move  up  through  the  layers  arriving  at 
the  user  in  their  original  form  and  sequence. 

The  closer  the  lower-level  protocols  match  the  services 
requested  by  the  higher-level  application  protocols,  the 
more  efficient  the  overall  information  flow  throughout  the 
network.  This  will  also  enable  the  information  system  to 
more  closely  mirror  the  special  style  and  needs  of  a  given 
organization  rather  than  allowing  the  system  chosen  to  force 
a  change  in  the  organization's  information  control  strategy 
[Ref.  20:  pp  390-391]. 

The  first  three  sections  of  this  chapter  may  all  seem 
like  an  unnecessary  academic  aside  but  the  need  for  identi¬ 
fication  of  USMC  specific  requirements  is  critical.  The 
keen  competition  for  diminishing  research,  development, 
production,  and  operating  funds  mandates  procurement  of 
existing  off-the-shelf  network  and  processing  components. 


This  must  be  done  to  reduce  development  costs  and  allow 
economic  logistics  and  maintenance  support.  It  should  not 
however,  reduce  our  efforts  to  properly  define  our  actual 
requirements.  The  extra  up  front  effort  will  ensure  that  we 
get  an  information  system  that  fits  our  needs.  One  that  not 
only  satisfies  our  user  specific  requirements  but  also  does 
not  have  expensive  unnecessary  features  accepted  just 
because  they  were  available.  After  the  user  requirements 
have  been  addressed  local  and  long  distance  communications 
interconnection  requirements  are  next. 

E.  INTERCONNECTION  REQUIREMENTS 

User  networking  requirements  should  be  the  next  logical 
evolutionary  step  after  application  identification  and 
information  flow  requirements  have  been  specified.  The 
ability  to  make  the  technology  decision  ( i. e. ,  LAN,  CBX, 
shared  processor,  or  a  combination  of  all  three)  should  be 
getting  near. 

As  the  capability  of  software  packages  on  local  networks 
grow  to  include  distributed  database  management,  electronic 
mail,  text  editing,  file  transfer,  etc,  so  will  the  desire 
or  need  to  expand  the  geographic  coverage  of  the  system 
providing  these  services.  This  will  drive  up  the  need  for 
interconnection  of  local  networks,  either  directly  or 
through  wide  area  networks.  If  not  adequately  addressed  in 
the  planning  stages  of  local  network  design,  the  result  will 
be  efficient  pockets  of  high  speed  data  processing  and  data 
communications  systems  that  are  seriously  degraded  by  inef¬ 
ficient  slow  interconnection  solutions. 

1.  Local  Network  Interconnection 

All  computer  networks  are  a  collection  of  computing 
resources  (hosts,  terminals,  communications  controllers, 
servers, etc, )  each  of  which  can  be  viewed  as  a  node.  Nodes 
are  connected  by  communications  channels  (physical  and 
logical)  which  provide  the  paths  to  send  and  receive 


messages.  The  node  can  be  one  or  multiple  hosts  with 
associated  terminals  or  an  independently  operated  terminal 
not  associated  with  a  particular  host.  All  terminals  can 
connect  directly  to  the  host  or  may  use  communications 
processors  or  controllers  along  the  way  for  connection  to  a 
particular  host.  A  node  could  also  be  connected  to  the 
network  to  serve  as  a  message  handling  node  or  gateway  to  an 
adjoining  local  or  long  distance  network. 

As  discussed  in  Chapter  2,  local  networks  are  often 
distinguished  from  long  distance  networks  by  the  area  they 
cover  and  the  speed  at  which  they  operate.  Local  networks 
are  also  oriented  toward  satisfying  user  information 
processing  needs  vice  the  long  distance  network  orientation 
toward  communications  services.  The  benefits  of  the  high 
speed  local  networks  can  be  greatly  diminished  if  intercon¬ 
nections  are  not  minimized.  However,  when  local  networks 
require  extension  or  connection,  a  bridge  is  the  device  used 
most  often. 

The  bridge  interconnects  two  logical  local  area 
networks  using  the  same  or  different  physical  media  but 
having  common  higher-layer  protocols.  It  allows  stations  on 
different  LANs  to  communicate  as  if  they  were  on  the  same 
LAN.  The  bridge  differs  from  a  repeater  because  it  is  an 
intelligent  filtering  device  used  to  store-and-f orward 
frames  moving  between  the  LANs.  The  repeater  is  used  only 
to  interconnect  cable  segments  on  the  same  LAN.  Figure  3. 4 
is  an  example  of  two  local  networks  interconnected  by  a 
bridge.  The  bridge  looks  just  like  another  station  on  each 
of  the  LANS  but  offers  some  very  useful  capabilities.  The 
bridge  in  Figure  3. 4  reads  all  the  packets  transmitted  on 
LAN  A  accepting  only  those  addressed  to  stations  on  LAN  B. 
It  receives  each  packet  using  the  access  protocol  from  LAN 
A,  buffers  the  packets,  then  uses  the  appropriate  protocols 
to  access  LAN  B  and  pass  on  the  traffic  to  the  station  on  B 


for  which  it  was  intended.  It  does  the  same  thing  for  LAN  B 
traffic  going  to  LAN  A.  The  bridge  makes  no  modification  to 
the  content  or  format  of  the  data  in  the  packets. 

LANs  are  limited  by  propagation  delay,  signal  atten¬ 
uation,  and  distortion  (normally  a  function  of  the  number 
of  stations  and  distance  to  be  covered).  The  bridge  over¬ 
comes  these  problems  by  removing  the  traffic  from  the 
originating  LAN  then  passing  it  to  the  destination  LAN. 
This  reduces  the  contention  for  access  on  each  LAN  and 
increases  the  number  of  addressable  stations  as  well  as  the 
distance  covered  by  the  LAN  extension.  It  also  improves 
reliability  because  the  loss  of  one  LAN  does  not  bring  down 
all  stations  like  it  would  if  all  were  connected  to  the  same 
LAN.  It  could  add  a  security  feature  by  creating  a  connec¬ 
tion  between  classified  and  unclassified  networks  for 
passage  of  unclassified  traffic  only. 

Special  care  should  be  taken  when  planning  a  local 
network  strategy  that  employs  bridges.  The  objective  is  to 
achieve  high  speed  and  high  throughput  connection  between 
LANs  thereby  avoiding  bottlenecks.  Careful  traffic  studies, 
minimal  differences  in  local  network  protocols,  and  adequate 
bridge  buffer  size  will  all  help  achieve  this  goal. 
Dissimilar  local  network  interconnection  or  local  network 
interconnection  through  long  distance  or  wide  area  networks 
presents  additional  problems.  These  problems  must  be  solved 
using  more  than  a  simple  filtering  pass  through  device  like 
the  bridge. 

2.  Local/Long  Distance  Network  Interconnection 

Long  distance  computer  network  interconnection  is 
much  like  local  to  long  distance  voice  telephone  switching 
and  terminal  equipment  networks.  Local  switches  and 
networks  use  various  unique  features  to  enchance  the 
services  offered  to  local  subscribers.  Abbreviated  dialing 
and  conferencing  are  a  couple  of  examples.  However,  when 


LAN  B 


they  desire  to  extend  the  connection  outside  the  local  area, 
they  must  adhere  to  standard  physical  and  logical  procedures 
for  interconnection  of  their  long  distance  calls.  A  common 
hierarchical  structure  of  toll  centers,  primary  centers, 
sectional  centers,  and  regional  centers  work  together  with 
standard  circuit  switched  voice  oriented  switching  and 
transmission  techniques  to  interconnect  end  offices  which 
use  centrally  controlled  star  topologies.  The  long  distance 
calls  go  only  as  high  in  the  hierarchical  structure  as 
necessary  for  connection  to  the  desired  switch  and  ulti¬ 
mately  the  desired  destination  terminal.  Calls  are 
dynamically  routed  to  control  the  flow  and  prevent 
congestion  at  individual  switching  centers  or  across  indi¬ 
vidual  links.  Interconnection  in  a  standard  network  like 
this  presents  few  problems  for  the  local  network  designer. 
He  just  follows  the  established  network  physical  and  logical 
design  parameters  for  interconnection  and  transmission  of 
his  long  distance  traffic. 

The  long  distance  interconnection  compatibility 
requirements  for  local  computer  communications  networks  is 
significantly  more  complex.  The  long  distance  telephone 
network  evolved  to  its  current  refined  highly  compatible 
state  over  many  years  and  offers  local  telephone  network 
designers  a  stable  standard  set  of  design  objectives  and 
interface  requirements.  Local  data  handling  networks  have 
only  recently  evolved  from  independently  developed  often 
incompatible  vendor  network  designs.  As  these  networks  grew 
in  number,  these  same  vendors  developed  their  own  long 
distance  network  switching  and  transmission  architecture  or 
simply  used  those  employed  in  their  mainframe  time-shared 
computer  configurations.  These  architectures  were  specifi¬ 
cally  designed  to  handle  traffic  generated  by  equipment  and 
protocols  unique  to  their  own  individual  designs.  The 
communications  services  and  protocols  used  were  also 


specially  designed  to  offset  problems  unique  to  long 
distance  networks.  Like  the  long  distance  telephone  system, 
long  distance  data  networks  are  inherently  less  reliable  due 
to  the  effects  of  noise  generated  in  long  distance  transmis¬ 
sion  media.  Changes  from  one  format  to  another  depending  on 
the  network  or  link  used  also  contribute  to  this  problem. 
Because  of  the  distances  involved  and  diversity  of  communi¬ 
cations  channels  used  (telephone,  leased  line,  satellite, 
and  microwave)  getting  bandwidth  for  high  speed  service  is 
an  expensive  proposition.  Therefore,  complex  switching  and 
protocol  techniques  are  used  to  maximize  the  efficient  use 
of  this  expensive  commodity  called  bandwidth.  They  also  try 
to  offset  the  network  reliability  problems.  Switching, 
encapsulation,  fragmentation  and  reassembly,  connection 
control,  flow  control,  error  control,  synchronization, 
sequencing,  addressing,  multiplexing,  and  transmission 
services  are  all  examples  of  parameters  used  to  route 
traffic,  to  improve  reliability,  or  to  offer  special 
services  [Ref.  20:  pp.  375-385].  One  or  all  of  these  param¬ 
eters  can  differ  depending  on  which  long  distance  network  is 
selected. 

This  presents  a  classic  conflict  of  interest  between 
local  and  long  distance  networks.  The  long  distance  network 
uses  complex  protocols  that  sacrifice  processing  time  to 
reduce  bandwidth  requirements  and  effectively  use  channel 
capacity.  Local  networks,  on  the  other  hand,  use  simple 
protocols  that  waste  channel  capacity  to  reduce  processing 
time  [Ref.  21:  p.  71].  Interconnection  of  these  two  diverse 
network  protocol  sets  is  done  by  using  a  translation  device 
called  a  gateway.  The  gateway  is  more  complex  than  the 
bridge  device  previously  described  because  of  the  many 
differences  between  local  and  long  distance  network  proto¬ 
cols.  Addressing  schemes,  packet  sizes,  network  interface 
protocols,  time-outs,  error  recovery  techniques,  status 


reporting  procedures,  routing  techniques,  access  controls, 
and  connection  or  connectionless  service  all  represent 
differences  the  gateway  may  be  designed  to  resolve  [Ref.  22: 
pp.  168-169]. 

The  layered  protocol  architectures  of  the  OSI/RM  and 
INTERNET  Model  (developed  from  ARPANET  experience)  were 
discussed  in  Chapter  2.  Digital  Equipment  Corporation  (DEC) 
Digital  Network  Architecture  (DNA)  and  IBM's  System  Network 
Architecture  (SNA)  offer  two  additional  protocol  architec¬ 
tures  used  in  today' s  long  distance  networks.  Figure  3.  5 
shows  how  the  SNA  and  DNA  protocol  architectures  match  up 
against  the  OSI  and  INTERNET  model  architectures.  The 
following  amplifies  the  functions  of  the  DNA  and  SNA 


architectures. 


a.  Digital  Network  Architecture  (DNA) 

DNA  uses  a  strong  protocol  layering  with  a  data 
link  control  level,  a  logical  connection  or  virtual  circuit, 
and  a  user  application-level  much  like  ARPANET.  The  network 
service  protocol  (NSP)  is  a  lot  like  the  transport  protocol 
in  ARPANET  but  DNA  does  not  distinguish  between  host 
computers  and  switching  nodes  (IMPS  in  the  ARPANET).  Some 
of  the  DNA  system  nodes  run  user  programs,  some  switch 
packets,  and  others  do  both.  DNA  is  divided  into  the  five 
function  layers  (Figure  3.6). 

(1)  Physical  Layer.  The  physical  layer 
performs  the  same  functions  as  the  physical  layer  of  the  ISO 
OSI/RM  described  in  Chapter  2.  Electrical  characteristics 
like  clocking,  signalling,  and  carrier  service  interfaces 
are  the  functions  of  this  layer. 

(2)  Data  Link  Control  Layer.  This  layer  uses 
a  DNA  unique  protocol  called  digital  data  communications 
message  protocol  (DDCMP)  to  create  a  sequential  error-free 
communications  path  between  adjacent  nodes  for  the  transfer 
of  data  blocks. 


(3)  Transport  Layer.  This  layer  is  used  for 
transporting  messages  from  the  source  to  the  destination 
node.  It  uses  a  route  table  and  routing  algorithm  to 
provide  an  adaptive  scheme  for  end-to-end  path  establishment 
through  intermediate  nodes.  It  is  highly  dependent  on  the 
Network  Services  layer  for  path  establishment. 

(4)  Network  Services  Layer.  This  layer  uses 
NSP  to  create  and  manage  the  logical  path  between  users. 
With  the  help  of  the  transport  layer  it  uses  flow  control 
and  buffer  management  to  uniquely  route  each  packet  then 
reassemble  them  at  the  destination. 

(5)  Application  Laver.  Application  functions 
for  services  like  file  transfer,  terminal  control,  database 
transaction  requests,  and  data  transfers  program- to-program 
are  accomplished  through  independent  logical  links  at  this 
layer. 

b.  System  Network  Architecture  (SNA) 

IBM  also  uses  a  layered  protocol  architecture 
(Figure  3.7).  This  architecture  is  oriented  toward  secon¬ 
dary  terminal  nodes  accessing  a  single  or  small  number  of 
primary  main  computer  nodes  rather  than  equally  capable 
nodes  connecting  on  equal  footing.  All  of  the  layers  can 
reside  on  the  host  or  link  path  controls  can  be  taken  off 
the  host  and  handled  by  software  in  a  separate  communica¬ 


tions  controller. 


Path  access  can  also  be  handled  outside 


the  host  by  a  separate  front-end  processor.  The  user  gets  a 
sequential  serial  bit  stream  making  the  network  appear 
transparent  regardless  of  the  topology,  route,  or  transmis¬ 


sion  media  used. 


Network  addressable  units  called  sessions 


establish  logical  connections  via  the  SNA  protocol  layers. 

(1)  Data  Link  Control  Laver.  This  layer  uses 
a  unique  Synchronous  Data  Link  Control  (SDLC)  protocol  to 
package  and  transmit  the  data  bitstream  from  the  higher 
layers  on  the  point-to-point  or  multi-point  switched  or 
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non-switched  connections.  SDLC  is  totally  transparent  to 
the  higher  protocols  and  does  not  attempt  to  interpret  any 
of  the  data  structures  coming  from  them.  It  simply  uses 
its  own  packaging  and  control  structure  to  pass  the  raw 
data  error  free. 

(2)  Path  Control  Laver.  The  path  control 
layer  controls  congestion  by  dynamic  packet  routing  in  the 
communications  subnetwork.  It  can  improve  efficiency  by 
packetizing  outgoing  messages  and  depacketizing  incoming 
messages. 

(3)  Data  Flow  Control  Layer.  This  layer 
carefully  matches  varying  types  of  input  from  different 
users  to  ensure  user  request/response  flow  and  flow 
integrity  are  maintained.  Selecting  full  duplex  or  half 
duplex,  user  modes,  and  message  grouping  are  all  examples  of 
the  services  offered  by  this  layer. 

(4)  Presentation  Services  Laver.  Data 
transformations,  additions,  and  editing  functions  are 
performed  in  this  layer  to  ensure  the  data  is  in  the  proper 
format  for  terminal  presentation. 

(5)  End  User  Layer.  Each  network  element  that 
can  send  or  receive  data  is  assigned  a  network  address  and 
is  known  as  a  network  addressable  unit  (NAU).  The  network 
address  uniquely  identifies  the  element  regardless  of 
whether  it  is  a  device  (terminal  or  terminal  control  unit), 
a  program  ( like  an  application  program  in  a  cluster 
controller  or  host  processor),  or  a  part  of  an  SNA  access 
method.  The  network  address  contains  the  information 
necessary  to  route  data  to  its  destination.  A  hierarchy  of 
domains  exist  for  network  control  and  each  domain  is 
controlled  by  a  System  Services  Control  Point  (SSCP).  These 
SSCPs  communicate  with  each  other  in  the  overall  management 
of  the  network. 


SNA  Protocol  Architecture. 


A  little  over  6  years  ago,  when  the  ARPANET  (  later 
the  DOD  INTERNET)  model  had  not  yet  matured,  the  U.  S.  Marine 
Corps  was  given  permission  to  build  an  interim  temporary 
long  distance  data  network.  This  network  was  designed  to 
satisfy  data  transmission  and  communication  requirements 
between  mainframes  at  several  Marine  Crops  installations. 
The  result  was  the  Marine  Corps  Data  Network  (MCDN)  (Figure 
3.8).  Table  VII-IX  provide  the  breakdown  of  hosts,  FEPs, 
sub  areas,  site  IDs,  and  trunk  group  identifiers  that 
correspond  to  the  the  Figure  3.8  numbers  and  letters. 

MCDN  is  a  common-user,  data  communications  network 
which  provides  terminal- to-computer  and  computer-to-computer 
communications  for  all  functional  Marine  Corps  Automated 
Information  Systems  (AIS).  It  is  primarily  designed  for  the 
supporting  establishment  and  Fleet  Marine  Force  units  in 
garrison.  Since  the  mainframes  were  IBM,  SNA  was  the 
logical  choice  for  the  local  and  long  distance  protocol 
architecture.  This  architecture  is  based  on  the  use  of 
communications  processors  (NCR  COMTENs)  as  the  major  nodal 
elements  in  the  network.  All  terminals  connected  to  the 
network  are  given  access  to  any  host  computer  in  the  network 
in  an  on-line  interactive  mode.  Connectivity  between  nodal 
points  in  the  MCDN  is  provided  by  leased  commercial  tele¬ 
phone  circuits.  The  communications  processors  perform  the 
following  specific  functions: 

•  Front-end  processing  for  all  host  computers 

•  Switching/line  control  for  all  terminals 

•  Network  communications  functions 

All  computer  terminals  and  remote  job  entry  (RJE) 
work  stations  gain  access  to  MCDN  via  dedicated/dial-up 
circuits  to  the  nearest  communications  processor.  Extensive 
use  of  terminals  served  by  polled,  multi-drop  circuits  are 
used  to  minimize  circuit  costs  while  facilitating 
interactive  terminal- to-computer  communications. 
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TABLE  VII 
MCDN  DESIGNATIONS 


REGIONAL  CONTROL 

MCDN 

NODE 

SU8NOOE 

DFSIGNA 

MCCOPA  ALBANY 

ALA 

4TH  MAW  (NEW  ORLEANS) 

NOL 

RASC  CAMP  LEJEUNE 

CLB 

FMFLANT  (NORFOLK) 

NFO 

MCRO  PARRIS  ISLAND 

PIK 

RASC  CHERRY  POINT 

CPY 

RASC  HAWAI I 

HIF 

MCAS  KANEOHE  BAY 

KBJ 

MCCOPA  QUANTICO 

MQG 

HQMC 

HQ  I 

RASC  CAMP  PENOLETON 

CPP 

RASC  EL  TORO 

ETE 

MCAS  YMA 

YMH 

MCLB  BARSTOW 

BAM 

MC3  29  PALMS 

TPN 

MCRO  SAN  DIEGO 

SDO 

RASC  OKINAWA 

OKR 

RJE  CAMP  FOSTER 

OKQ 

MCAS  IWAKUNI 

IWZ 

MCCOPA  KANSAS  CITY 

KCT 

MCRSC  OVERLAND  PARK 

RFC 

TABLE  VIII 

MCDN  SUBAREA  ASSIGNMENTS 


HQSIS 

NCOS 

location 

1-2 

31-32 

quantico 

3 

33 

HEADQUARTERS 

4-5 

34-35 

KANSAS  CITY 

6 

36 

RESERVE  FORCES 

7-8 

37-38 

ALBANY 

26 

56 

NEW  ORLEANS 

9-10 

39-40 

CAMP  LEJEUNE 

1  1 

41 

NORFOLK 

12 

42 

CHERRY  POINT 

13 

43 

PARRIS  ISLAND 

14-15 

44-45 

CAMP  PENDLETON 

16 

46 

BARSTOW 

17 

47 

EL  TORO 

18 

48 

SAN  DIEGO 

19 

49 

29  PALMS 

20 

50 

YUMA 

21 

51 

CAMP  SMITH 

22 

52 

KANEOHE  8AY 

23 

53 

CAMP  K1NSER 

24 

54 

CAMP  FOSTER 

25 

55 

IWAKUN! 

TABLE  IX 

NODE  ID,  DESTINATION  ID,  AND  LINE  NUMBER 


NODE  !  9 

pc5"~  ;n 

NODE  anO  l!nE 

TTNJE04,  TTNJE05 

KANSCI TY 

20 

GGMJEO  t ,  GGNJE02 

QUANTICO 

22 

GINJE03 

HQMC 

24 

AANJE07,  AANJE08 

ALBANY 

25 

PPNJE14,  PPNJE l 5 

CAMPPENO 

27 

PMNJE  1  6 

BARSTOW 

29 

PENJE17 

ELTORO 

30 

P0NJE18 

SAND  1  EGO 

31 

88NJE09 ,  88NJEI0 

CAHPLEJ 

32 

FFNJE2I 

CAMPSMI TH 

33 

RRNJE23 

CAMPK1N 

34 

8YNJEI2 

CHERRYPT 

35 

SKNJE  13 

PARRISLE 

36 

R2NJE25 

IWAKUNI 

37 

TCNJE06 

RESSUPCT 

38 

30NJE ! I 

NORFOLK 

39 

RCNJE24 

CAMPFOST 

40 

FJNJE22 

KANBAY 

41 

PHNJE20 

mcasyuma 

42 

PNNJE19 

29PALMS 

43 

ALNJE26 

NEWORL 

44 

44 


MCDN  provides  a  responsive  reliable  synchronous  time 
division  multiplexed  circuit  switched  long  distance  data 
transmission  service  for  the  many  users  at  each  site. 
However,  now  that  DDN  has  been  designated  as  the  official 
long  distance  data  network  for  all  of  DOD,  the  Marine  Corps 
is  attempting  to  transition  to  DDN  for  long  distance  connec¬ 
tivity.  The  Marine  Corps  and  the  Defense  Communications 
Agency  (DCA),  in  conjunction  with  several  prime  and  support 
contractors  for  both  networks,  are  attempting  to  develop  and 
test  an  efficient  protocol  conversion  technique  which  will 
permit  this  transition.  A  five  phase  test  and  evaluation 
effort  began  in  November  1985  to  address  the  following 
issues: 

•  IBM  SNA  architecture  compatibility  with  the  DDN 

•  Sub-network  management 

•  Network  diagnostics 

•  Remote  initial  load  of  remote  processors 

•  Response  times  as  guaranteed  by  DDN  system  specifica¬ 
tions 

•  Dedicated  packet  switched  node  (PSN)  resources 

The  test  was  designed  to  gradually  build  from  a  single  pair 
of.  nodes,  testing  the  basic  interface,  to  multiple  nodes 
testing  the  connectivity  with  actual  operational  traffic 
loads. 

a.  Phase  I 

This  phase,  conducted  in  January  1986,  was  used 
to  gather  statistics  like  host  utilization,  line  utiliza¬ 
tion,  response  times,  and  throughput  on  the  current 
configuration  being  used  by  MCDN.  This  baseline  data  will 
be  used  as  a  benchmark  for  comparing  the  performance  of  the 
MCDN  in  its  current  leased  line  configuration  versus  the 
DDN. 

b.  Phase  II 

The  configuration  in  Figure  3.9  will  be  usid  in 
Phase  II,  March  1986,  to  ensure  that  a  session  can  be 


established  and  maintained  through  the  DDN.  A  COMTEN 
processor  currently  being  used  for  local  processing  at 
Kansas  City,  Mo. ,  will  be  used  to  test  the  newly  developed 
NCR  COMTEN  X.  25  and  Communications  Network  Service  (CNS) 
software.  This  new  software  will  be  exposed  to  the  opera¬ 
tional  DDN  environment  for  the  first  time  during  this  test. 

c.  Phase  III 

The  configurations  in  Figure  3. 10  will  be  used 
during  Phase  III,  April  1986,  to  establish  the  optimal 
equipment  configurations  for  DDN  connectivity.  Initially, 
only  Kansas  City  and  Quantico  will  be  connected  then  Albany, 
Camp  Lejeune,  and  Camp  Pendleton  will  be  brought  on  line. 

d.  Phase  IV 

Phase  IV,  May  1986,  will  simulate  MCDN  in  an 
operational  mode  with  DDN  using  the  configuration  estab¬ 
lished  during  Phase  III.  The  same  statistics  collected 
during  Phase  I  will  be  collected  during  this  phase  for 
comparison. 

e.  Phase  V 

Phase  V,  June  1986,  will  be  used  to  analyze  test 
results  and  produce  a  .test  report. 

The  results  of  this  test  will  have  a  significant 
impact  on  how  the  Marine  Corps  plans  to  provide  future  long 
distance  connectivity  to  local  subscribers.  The  decision  on 
how  this  will  be  done  also  impacts  decisions  on  local 
network  protocol  specifications.  Will  the  Marine  Corps 
continue  to  think  in  terms  of  the  centralized  IBM  mainframe 
configurations  used  now?  Will  local  networks  be  connected 
through  these  hosts  which  are  in  turn  connected  through  DDN 
as  shown  in  Figure  3.11?  Maybe  test  results  will  show  that 
this  is  not  an  efficient  reliable  solution.  This  may  leave 
local  networks  connected  through  the  IBM  hosts  which  will 
continue  to  be  connected  through  MCDN  (Figure  3.12).  Will 
the  entire  centralized  processing  philosophy  soon  change  to 


a  more  distributed  perhaps  asynchronous  approach  as  depicted 
in  Figure  3. 13?  If  so,  should  the  SNA  synchronous  protocols 
be  forced  upon  all  local  networks?  Can  third  and  fourth 
generation  CBX's  with  associated  wideband  digital  trunking 
capabilities  be  considered  for  use  as  bridges  and  gateways 
for  local  as  well  as  long  distance  connectivity?  Will 
public  switched  packet  data  networks  be  used  for  future  long 
distance  connectivity  as  shown  in  Figure  3. 14?  If  so,  which 
ones  and  what  protocols  do  they  use?  These  and  many  more 
questions  must  first  be  answered  in  order  to  develop  an 
overall  network  strategy.  This  will  ensure  that  unnecessary 
expensive  connections,  bridges,  gateways,  and  protocol 
conversion  requirements  are  not  imposed  on  the  all  LAN 
specifications  just  to  cover  all  contingencies. 

Identification  of  the  location  and  type  of 
information  sources  outside  the  local  area  allows  identifi¬ 
cation  of  the  long  distance  network  best  suited  for  long 
distance  interconnection.  Since  most  of  the  traffic  is 
local,  these  parameters  may  not  be  the  driving  force  in 
local  network  access  and  communications  strategies  but  they 
cannot  be  ignored.  This  reduces  the  chance  of  selecting  a 
local  network  strategy  that  is  rendered  woefully  inefficient 
or  even  worse  cannot  pass  traffic  when  connected  to  a  long 
distance  network. 

Common  layer  separation  and  functional  responsi¬ 
bility  assignment  was  the  intent  of  the  OSI/RM  and  the  DOD 
INTERNET  concepts.  However,  the  previous  existence  or 
concurrent  development  of  network  solutions  like  IBM  SNA 
and  Digital  Equipment  Corporation  (DEC)  Digital  Network 
Architecture  (DNA)  resulted  in  public  long  distance  data 
networks  that  use  different  protocols.  In  the  case  of  MCDN 
and  DDN,  military  long  distance  data  networks  that  use 
different  protocols  for  encapsulation,  switching,  and  trans¬ 
mission  also  exist.  The  Marine  Corps  must  develop  an 


Figure  3. 11  Local  Networks  Connected 
Through  MCDN  Hosts  and  DDN. 
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overall  local/long  distance  network  strategy.  This  will 
lead  to  choosing  only  one  network  for  long  distance  inter¬ 
connection  or  the  adoption  of  multiple  translation  and 
mapping  protocols  within  all  local  networks.  The  fact 
remains  that  local  networks  will  be  influenced  by  the  proto¬ 
cols  used  in  already  established  and  emerging  long  distance 
networks.  Hard  decisions  must  be  made. 

After  careful  consideration  of  user  requirements 
translated  into  services  and  higher-level  protocols  as  well 
as  long  distance  network  interconnection  requirements,  a  LAN 
may  well  be  the  technology  selected  to  satisfy  the  local 
network  requirement.  This  only  begins  the  specif ication 
process.  Numerous  other  performance  oriented  operation  and 
management  requirements  must  be  included. 

F.  LAN  SPECIFICATIONS 
1.  General 

Coordinated  cooperation  between  user,  network 
designer,  and  contracting  specialists  is  never  more  critical 
than  during  the  specification  process.  What  you  get  in 
vendor  proposals  to  satisfy  actual  requirements  is  only  as 
good  as  the  detail  and  completeness  of  the  specifications 
prepared  for  the  solicitation  package.  Vague,  general,  and 
basic  specifications  just  give  the  vendor  an  opportunity  to 
submit  an  abundance  of  detail  on  the  features  of  his  own 
system  without  ever  having  to  translate  those  features  into 
required  operational  performance  capabilities.  To  this 
point,  the  LAN  specifications  have  been  oriented  toward 
satisfying  user  requirements. 

The  information  collected  ,  analyzed  ,  and  used  to 
determine  services  required  should  provide  answers  to  the 
following  (among  other)  questions: 

•  What  kinds  of  applications  and  services  will  be  needed? 

•  What  are  the  transmission  types  and  throughput 
requirements? 


•  Is  there  a  need  to  integrate  services  and  if  so  which 
ones? 

•  How  many  sites  and  what  distances  will  the  LAN  cover? 

•  Are  there  any  special  data  transfer  requirements? 

•  What  types  of  computing  and  communications  devices 
( computers,  printers  and  print  spoolers,  file  servers 
and  disc  drives,  plotters,  modem  servers,  emula¬ 
tors,  etc,)  must  be  handled  by  the  network? 

The  information  gathered,  the  answers  to  these  questions, 
and  the  local  and  long  distance  connectivity  considerations 
were  used  to  make  the  LAN  technology  decision.  The  latter 
also  introduced  the  first  of  the  many  support  considerations 
that  have  an  affect  on  the  LAN  4  specifications.  The  local 
and  long  distance  connectivity  identified  the  network  inter¬ 
face  requirements  (gateways,  bridges,  hosts,  etc,).  This 
information  can  all  be  directly  translated  into  LAN  specifi¬ 
cations.  However,  there  are  still  many  unanswered  questions 
like: 

•  What  are  the  future  growth  requirements? 

•  Who  will  install,  support,  and  maintain  the  network 
equipment? 

•  What  type  of  network  management  scheme  will  be  used  and 
what  functions  must  it  have? 

•  Are  there  any  other  special  constraints  or  requirements 
like  priority,  precedence,  reliability,  availability, 
security,  etc? 

2.  Performance 

Several  general  software  and  hardware  characteris¬ 
tics  can  be  added  to  the  specific  needs  already  stated. 
"User  friendly"  is  a  much  used  term  that  characterizes  the 
desire  and  sometimes  fear  of  every  non  technically  oriented 
user  about  to  acquire  a  new  and  unfamiliar  system.  The 
state  of  technology  today  permits  the  system,  software,  and 
hardware  designers  to  give  users  special  features.  These 
features  offset  the  technical  complexity  of  the  new  sophis¬ 
ticated  systems.  User  guides  and  manuals,  directories  of 
network  services,  and  online  menus  to  guide  the  user  through 
complex  operations  are  all  examples  of  techniques  used  to 


increase  user  friendliness.  Plans  for  how  operating  charac¬ 
teristics,  capabilities,  and  limitations  of  the  new  system 
will  be  introduced  to  prospective  users  is  a  critical  part 
of  system  specification  and  acceptance.  Knowledge  of  how 
the  vendor's  proposed  network  will  create  new  or  change 
existing  system  command,  planning,  engineering,  execution, 
control,  and  coordination  procedures  opens  the  door  for 
adequate  user  preparation.  If  necessary,  users  are  more 
willing  to  provide  input  on  tradeoffs  that  might  have  to  be 
accepted  for  other  critical  performance  features.  By  making 
the  user  a  part  of  this  decision  process,  he  will  be  more 
inclined  to  accept  and  help  resolve  future  system 
shortcomings  and  problems. 

LAN  throughput  is  directly  related  to  the  transmis¬ 
sion  medium,  access  method,  processing  capacity  at  each 
network  node,  and,  as  stated  before,  the  amount  of  protocol 
translation  required  for  interface  variations.  A  detailed 
quantitative  traffic  analysis  would  be  most  useful  for  the 
specification  document.  Traffic  types;  message  size,  integ¬ 
rity,  sequencing,  and  accountability;  link  speeds;  number  of 
connections;  response  times;  etc;  can  all  be  used  to  give 
the  vendor  accurate  and  specific  throughput  speed  require¬ 
ments.  Stringent  reliability  requirements  in  command  center 
type  operations  can  also  contribute  to  this  specification 
element.  Several  of  the  ongoing  government  funded  network 
modelling  and  traffic  handling  analysis  projects  may  prove 
to  be  an  invaluable  source  for  appropriate  future  throughput 
numbers. 

The  request  for  flexibility  in  the  specification  may 
seem  trite  but  there  must  be  some  insurance  that  the  system 
will  be  kept  modern  as  user  requirements  change.  Modular 
design  techniques  will  ensure  that  the  entire  system  does 
not  require  replacement  all  at  once.  Commercially 
available  software  tools  ensure  supportabi li ty. 
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Contractual  flexibility  is  the  key  to  substituting  modern 
components  during  the  life  of  the  contract.  This  may  be  the 
key  to  future  network  growth  to  handle  features  and  services 
like  video  teleconferencing,  artificial  intelligence  for 
automated  decision  aides,  common  user  reference  databases, 
speech  recognition  for  voice  mail  and  dictation,  integrated 
voice  and  data  plus  many  more. 

3 .  Faci li ties /Support 

Overlapping  development,  training,  manpower,  opera¬ 
tions,  logistics,  and  maintenance  costs  result  in  life-cycle 
resource  requirements  which  cannot  be  supported.  This  is 
especially  true  for  manpower  which  is  the  most  expensive 
element.  Therefore,  we  should  use  technology  to  reduce 
manpower  intensive  operations  within  any  information  system 
architecture.  Simply  substituting  newer  versions  of 
existing  physical  systems  or  even  worse  adding  additional 
systems  is  not  the  solution.  Technology  that  can  reduce 
costs  include:  embedded  intelligence  consisting  of  built-in 
test  equipment,  fault  detection,  isolation  and  restoral, 
fault-tolerant  design,  and  artificial  intelligence  (expert 
systems);  portable/reusable  software  to  reduce  development 
and  maintenance  costs;  throw  away  maintenance  to  reduce 
logistics  support  costs;  and  finally  centralized  operations 
and  maintenance  to  reduce  manpower  requirements.  Early 
identification  of  manpower  intensive  operations  in  existing 
functional  mission  requirt ments  and  explicitly  stated  opera¬ 
tions  and  maintenance  requirements  (capabilities  and  defi¬ 
ciencies)  in  the  requirements  documentation  will  facilitate 
potential  savings  opportunities. 

Organizations  use  various  approaches  to  management 
and  control  of  resources.  Most  military  organizations  have 
a  highly  centralized,  hierarchically  structured,  formal 
chain  of  command  while  some  are  more  decentralized.  Those 
thinking  about  putting  together  an  information  system 


architecture  that  uses  LAN  technology  should  realize  that 
they  imply  a  more  distributed  approach  to  sharing  informa¬ 
tion.  A  key  issue  is  support  for  these  distributed 
services.  Organizations  with  highly  centralized  resources 
and  well  defined  support  procedures  ( software  and  hardware 
development,  maintenance,  operations,  etc,)  may  not  be  able 
to  support  or  control  a  LAN  environment.  This  is  an  envi¬ 
ronment  where  powerful  personal  computers  are  physically 
separated  and  interconnected  to  database  managers  and 
servers.  Proper  characterization  of  this  new  environment 
would  provide  specific  well  defined  functional  control  and 
support  procedures.  It  is  these  procedures  that  are  used  to 
specify  and  evaluate  potential  network  technical/ 
performance,  processing,  communications  and  maintenance 
features  as  well  as  hardware  configurations. 

The  paucity  of  funds  for  future  operations  will  not 
permit  a  separate  maintenance  support  contract  for  every  LAN 
installed  aboard  a  base.  Yet,  as  users  become  more  familiar 
with  and  dependent  upon  technologically  improved  data 
systems,  they  will  impose  increasingly  more  strict  require¬ 
ments  on  them.  Like  the  current  telephone  system,  these  new 
systems  will  be  expected  to  be  available  24  hours  a  day,  7 
days  a  week  [Ref.  23:  p.  5-6]  .  Who  will  provide  the  day-to- 
day  maintenance  and  network  control  support  for  LANs?  Base 
and  Station  Communications  Electronics  Officers  (CEO) 
already  feel  strapped  for  people  to  maintain  existing  cable 
plant  and  switching  equipment.  In  addition,  the  current 
feeling  among  many  CEOs  is  that  LANs  are  data  processing 
systems  that  should  be  operated  and  maintained  by  those  who 
own  them.  Marine  Corps  data  processing  facilities  have  the 
experience  in  network  management  of  computers  and  computer 
communications  networks  (MCDN).  However,  they  too  contend 
that  they  don't  have  the  people  nor  the  desire  to  support 
LANs  not  directly  associated  with  their  own  data  processing 


facilities.  Will  computers  and  data  communications  someday 
become  so  commonplace  that  every  organization  has  someone 
capable  of  administering,  managing,  and  maintaining  a  local 
area  network?  This  is  not  very  likely.  Once  again,  an 
overall  Marine  Corps  maintenance  strategy  is  in  order.  If 
local  networks  really  will  become  an  integral  part  of  the 
Marine  Corps'  data  processing  and  communications  network 
strategy,  then  appropriate  staffing  and  facilities  improve¬ 
ments  to  existing  CEO  or  Automated  Services  Center 
organizations  should  be  planned.  At  the  very  least,  someone 
(probably  the  CEO)  should  assume  responsibility  for  an 
overall  base  cable  plant  improvement  plan.  This  plan  should 
include  provisions  for  local  area  networks.  Planned  fiber 
optic  cable  installations  like  the  one  at  Iwakuni,  Japan  and 
T1  carrier  backbone  systems  like  the  one  going  in  to  support 
the  new  Northern  Telecom  switchboard  installation  at  Camp 
Pendleton,  Ca  should  be  considered  when  planning  procurement 
and  installation  of  future  LANs.  At  a  time  when  everyone  is 
looking  for  compensatory  personnel  reductions,  personnel 
increases  for  LAN  support  will  be  hard  to  get.  All  the  more 
reason  to  make  them  a  part  of  a  coordinated  support 
strategy.  This  will  be  necessary  for  whatever  data 
processing  and  support  strategy  we  adopt.  These  decisions 
must  then  be  reflected  in  the  individual  LAN  procurement 
specifications. 

4.  Network  Management 


Many  defense  systems  support  hundreds,  even  thou¬ 
sands  of  users  distributed  around  the  world.  USMC  system 
designers  must  be  aware  of  the  specific  performance  status 
report  requirements,  administration,  and  control  functions 
they  require.  These  functions  will  be  performed  by  a  LAN 
control  center  and  network  operations  center  when  directly 
connected  to  one  of  these  networks.  Interfacing  to  DOD 
networks  like  DDN,  most  likely  will  require  status  and 


service  access  reports  at  least  down  to  the  switching  node 
level.  Perhaps  not  every  LAN  will  need  a  dedicated  network 
control  center  but  the  lowest  level  for  a  full  time  manned 
network  control  center  (i.e.  base,  region)  should  be  part  of 
the  overall  network  strategy  discussed  earlier  in  this 
chapter.  Those  LANs  without  full  time  centers  should  still 
be  capable  of  collecting  basic  traffic  and  usage  statistics 
along  with  the  ability  to  report  error  or  fault  conditions 
to  the  responsible  network  control. 

Every  LAN  will  require  administrative  support  to 
maintain  a  record  of  cable  plant  routes,  access  points, 
active  users,  authorized  access  levels,  etc.  Adding  and 
removing  stations  should  be  possible  without  bringing  down 
the  entire  network  and  without  extensive  disruptive  routing 
reconfigurations.  Specific  procedures  and  responsibilities 
for  configuration,  reconfiguration,  trouble  reporting, 
restoral  coordination,  and  all  other  administrative  and 
operational  day-to-day  network  management  requirements 
(Figure  3.15)  should  be  developed  and  accepted  before  the 
LAN  specification  is  final.  This  will  ensure  that  those 
responsible  specify  what  is  needed  in  the  way  of  system  and 
network  support  in  the  requirements  and  specification 
process. 

5.  Security 

As  the  number  of  people  with  LAN  access  increases  so 
does  the  information  security  threat.  Add  to  this  the  addi¬ 
tional  threat  posed  by  network  interconnection  and  the  need 
for  stringent  security  procedures  becomes  obvious.  To  prop¬ 
erly  develop  security  measures  or  countermeasures,  this 


threat  has  to  be  classified  and  evaluated. 


Is  the  threat 


passive  where  someone  without  proper  access  only  monitors 
traffic  but  doesn't  alter  it?  Is  it  active  where  he  actu¬ 
ally  alters  the  information?  Will  the  unauthorized  access 
be  gained  by  tapping  the  cable  used  to  connect  LAN  stations 


or  through  a  bridge  or  gateway  from  a  connected  network? 
LANs  (especially  the  bus  and  tree  configurations)  are 
particularly  susceptible  to  the  passive  threat  by  their 
broadcast  nature.  Everything  transmitted  on  the  bus  is 
received  by  anyone  connected.  Complete  segregation  and 
physical  security  of  a  special  classified  LAN  is  one  answer. 

Physically  protecting  all  stations  and  cable  plant, 
using  a  token  passing  ring  network  with  a  central  token 
controller,  and  using  approved  encryption  devices  between 
the  terminals  and  the  network  are  all  methods  for  improving 
security.  In  this  configuration,  often  called  the  system 
high  mode,  all  data  processing  information  is  treated  as 
having  the  same  security  level  -  the  highest  level  in  the 
system  [Ref.  24:  p.  117].  This,  however,  prevents  the 
secure  network  from  taking  advantage  of  the  data,  support, 
and  long  distances  services  offered  by  interconnection  to 
other  networks. 

A  great  deal  of  work  is  being  done  on  a  more  appro¬ 
priate  strategy  called  multilevel  security.  This  technique 
allows  information  at  various  security  levels  as  well  as 
users  with  different  security  clearances  to  access  and  use 
the  LAN  simultaneously.  This  is  done  through  a  combination 
of  end-to-end  encryption  of  classified  information  and  the 
joint  use  of  a  secure  operating  system,  trusted  software, 
and  physical  protection.  DOD  has  tended  to  implement  end- 
to-end  encryption  only  because  the  addition  of  other  methods 
adds  cost  and  complexity  to  all  of  the  system  aspects-- 
software,  hardware,  and  management.  A  second  reason  is  the 
fear  that,  no  matter  how  well  designed,  software  is  still 
more  susceptible  to  passive  modification  and  tampering.  NSA 
is  currently  working  on  the  multi-level  technique  with  a 
system  called  BLACKER.  This  approach,  although  considered 
by  many  to  be  more  complex  than  some  other  approaches,  fits 
well  in  the  OSI  protocol  model  and  most  likely  will  be  the 
accepted  system  for  some  time  [ Ref.  24:  p.  118] . 


The  multilevel  security  approach  will  likely  take  a 
back  seat  until  the  technology  can  demonstrate  sustained, 
accurate, economic,  and  adequate  protection  for  classified 
material.  The  National  Bureau  of  Standards  has  generated  a 
great  deal  of  interest  in  their  work  on  Data  Encryption 
Standard  (DES)  chips  for  LAN  network  interface  units.  This 
work  includes  work  on  the  protocol  layer  for  implementing 
DES  ciphers,  session  protocols  for  establishing  secure 
communications  and  the  most  important  aspect,  key  generation 
and  distribution.  Again  the  fear  is  that  the  key  distribu¬ 
tion  software  may  be  secure  when  originally  designed  and 
produced  but  what  prevents  tampering  and  modification  once 
it  is  fielded.  Full  general-purpose  operating  systems  have 
so  far  been  too  complex  to  be  totally  secure  so  most  multi¬ 
level  efforts  have  concentrated  on  protecting  portions  of 
the  software  with  trusted  kernels.  All  security  decisions 
are  made  in  the  trusted  kernel.  This  requires  another  set 
of  those  protocol  translations  or  mapping  processes  which  of 
course  degrades  system  performance.  The  true  challenge  for 
future  multilevel  secure  system  designers  is  security 
enforcement  without  overall  system  degradation  [Ref.  7:  pp. 

1 1 1-65- 1 1 1-66]  . 

Below  che  security  classification  level,  non  secure 
LANs  also  require  certain  security  features  to  protect 
information  being  shared  by  many  different  users.  The 

following  is  a  list  of  the  minimum  security  features  that 
should  be  offered  by  any  LAN: 

•  User  access  controls  (passwords)  which  provide  appro¬ 
priate  assurances  each  user  is  authorized  to  have 
access  to  system  resources. 

•  Intrusion  protection  methods  to  protect  against  unau¬ 
thorized  users  who  may  be  able  to  break  through  access 
controls. 

•  Data  protection  and  recovery  techniques  to  permit  rapid 
recovery  of  information  if  primary  files  are  damaged  or 
lost. 

•  Appropriate  protection  for  a  common  database  ( like 
record  or  file  locks)  which  permits  actions( read,  edit, 
store,  etc,)  dependent  upon  assigned  code. 


G.  SUMMARY 


LAN  specifications  should  not  be  a  broad,  general,  and 

i 

|  basic  statement  of  user  needs  added  to  a  selected  group  of  j 

I  low-level  technical  and  logical  performance  features  taken  j 

f  from  vendor  advertisements.  This  strategy  preselects  LAN  ' 

•  / 
technology  as  the  solution  essentially  eliminating  other 

technical  solutions  from  the  beginning.  A  more  appropriate 

strategy  is  one  that  adopts  a  system  versus  component 

approach  looking  from  the  top  down  rather  than  from  the 

bottom  up. 

This  strategy  incorporates  a  detailed  functional  charac¬ 
terization  of  user  needs  and  applications  translated  into 
higher-level  services  and,  where  possible,  higher-level 
protocols.  This  translation  is  then  augmented  by  intercon¬ 
nection  and  communications  services  required  by  these  needs 
and  applications.  The  up  front  work  permits  a  layered 
system  design  approach  which  concentrates  on  performance  and 
functionality  for  proper  selection  of  the  technology  best 
suited  to  satisfy  user  requirements.  Once  a  LAN  is  the 
technology  selected,  the  addition  of  expected  LAN  oriented 
performance  characteristics,  facilities  and  support,  network 
management,  security,  and  any  other  needed  features  and 
constraints  results  in  preparation  of  a  more  accurate  and 
complete  specification  document  for  the  solicitation 
package.  This  extra  effort  ensures  vendors  don't  have  the 
opportunity  to  submit  proposals  that  have  an  abundance  of 
detail  on  their  individual  system  features  without  ever 
translating  these  features  into  operational  performance 
capabilities.  The  next  step  in  the  LAN  specification  and 
selection  process  is  development  of  the  selection  criteria 
used  to  select  the  vendor  proposal  that  best  suits  system 
user,  manager,  and  support  requirements. 
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IV.  h  LM 


A.  GENERAL 

The  user  and  interconnection  requirements  augmented  by 
the  expected  general  performance,  facilities/support, 
network  management,  security,  and  other  feature  requirements 
stated  in  the  specification  document  should  be  directly 
translated  into  test  objectives  and  test  procedures  then 
used  as  evaluation  criteria.  Various  media,  topologies, 
access  methods,  and  other  items  may  be  appropriate  for  the 
specified  environment.  Hopefully,  many  different  local 
networks  submitted  in  vendor  proposals  will  satisfy  the 
elements  of  the  specifications.  The  next  question  is  how  to 
correctly  choose  the  local'  network  or  networks  that  will 
most  completely  satisfy  the  specified  requirements.  There 
is  still  some  danger  that  those  making  the  selection  will 
revert  to  the  general  categorization  of  vendor  offered  tech¬ 
nology  and  features  allowing  user  and  network  specific 
requirements  to  take  a  back  seat.  This  is  natural  because 
most  modeling  and  analysis  information  avrilable  in  recent 
public  periodicals  and  government  studies  concentrate  on 
this  type  of  evaluation.  The  information  contained  in  these 
reference  sources  should  be  used  as  a  supplement  to  rather 
than  a  substitute  for  the  specifications. 

Technological  variables  like  media,  topologies,  and 
access  methods  are  the  most  popular  categories  used  in 
recent  literature  to  compare  the  merits  of  existing  local 
area  networks.  The  individual  categories  are  often  compared 
separately  causing  many  to  discard  a  given  network  because 
the  access  method  or  topology  does  not  fit  the  required 
need.  This  is  a  bad  practice  because  other  features 
employed  by  the  complete  network  design  may  offset  the 
perceived  system  shortcoming.  It  appears  that  fashion  or 


technological  inertia  have  a  tendency  to  take  over  when  a 
new  solution  is  introduced.  It  is  important  to  realize  that 
there  may  be  no  single  solution  that  handles  the  entire 
problem.  A  full  solution  may  require  multiple  technologies 
working  together.  General  technological  comparisons  along 
with  quantitative  analyses  on  traffic  handling  capabilities 
can  give  those  responsible  for  the  choice  a  good  background 
in  common  industry  standards.  These  comparisons  also  give 
them  a  feel  for  the  performance  of  different  networks  under 
specified  traffic  loads. 

The  ability  to  build  a  prototype  network  on  which  actual 
user  applications  can  be  tried  obviously  offers  the  best 
assurance  that  a  vendor's  proposed  network  is  the  best  solu¬ 
tion.  This  however,  is  unrealistic  because  the  research  and 
development  money  to  undertake  such  a  task  for  every  poten¬ 
tial  LAN  requirement  is  simply  not  available.  LAN  specifi¬ 
cation  and  evaluation  document  preparers  can  however,  take 
advantage  of  lessons  learned  from  previous  prototype  and 
operational  LAN  network  installations.  Making  the  informa¬ 
tion  available  from  a  centrally  controlled  reference  data¬ 
base  would  offer  the  prospective  LAN  user,  designer,  and 
manager  an  incredibly  powerful  tool  for  network  design, 
specification,  installation,  and  evaluation.  Independently 
run  tests  and  evaluations  of  actual  networks  provide 
substantial  performance  characteristics  on  protocol  design 
and  compatibility,  traffic  handling  characteristics, 
geographic  coverage,  use  and  applications,  surviveability , 
expandability,  etc.  Documentation  of  experiences  that 
closely  approximate  U. S.  Marine  Corps  user  specific  applica¬ 
tions  and  networking  requirements  would  offer  a  tremendous 
repository  of  information.  It  may  even  allow  recommendation 
of  vendor  equipment  configurations  particularly  useful  in 
design  and  evaluation  efforts. 


Several  references  were  reviewed  as  part  of  the  research 
for  this  thesis.  Some  presented  problems  encountered  and 
lessons  learned  in  early  prototype  and  operational  LAN 
installations.  Others  offered  comparisons  of  major  techno¬ 
logical  variables  that  differentiate  LAN  types.  Still 
others  offered  current  industry  trends  that  are  likely  to 
impact  future  LAN  offerings.  On  a  rare  occasion,  a  refer¬ 
ence  was  encountered  that  offered  all  of  these  comparisons. 
The  point  here  is  that  although  periodicals  and  government 
reports  may  not  provide  a  complete  set  of  LAN  selection 
criteria,  their  use  as  a  common  information  and  reference 
tool  should  not  be  ignored.  The  hands  on  experience  and 
actual  data  collection  when  viewed  with  a  careful  eye  can 
add  the  experience  factor  missing  in  purely  theoretical 
analysis  and  forecasting. 

B.  USER/DEVELOPER  EXPERIENCE 

Capitalizing  on  previous  experience  can  be  both  a 
blessing  and  a  curse.  The  ability  to  begin  with  knowledge 
and  experience  gained  by  other's  mistakes  prevents  a  great 
deal  of  lost  time  trying  to  "reinvent  the  wheel"  and  in  this 
regard  is  most  helpful.  Unfortunately,  this  information 
also  has  a  tendency  to  narrowly  focus  the  concentration  of 
system  users,  designers,  and  managers  on  only  a  few  specific 
technical  aspects--as  stressed  throughout  this  thesis,  the 
danger  to  be  avoided.  Nonetheless,  this  information  can  be 
most  helpful  when  added  to  the  detailed  specification 
requirements  from  Chapter  2. 

A  LAN  prototype  network  test  was  conducted  in  early  1985 
by  the  Regional  Automated  Services  Center  (RASC)  at  Camp 
Pendleton,  Ca.  This  test  was  designed  to  determine  if  a 
local  network  could  be  used  to  simultaneously  support 
personal  computer  networks  requested  by  numerous  Camp 
Pendleton  User  Requirement  and  Information  Flow  (URIF) 
studies  as  well  as  improve  response  times  for  selected  3270 


terminals.  The  3270  terminals  were  connected  to  MCDN 
through  the  Camp  Pendleton  node.  After  research  and  discus¬ 
sion  with  several  potential  vendors,  a  prototype  LAN  using 
Racal/Milago ' s  PLANET  network  was  installed  to  test  the 
following  requirements: 

•  Multi-point  capability  for  devices  connected  to  the 
COMTEN^  s 

•  3270  bi-synchronous  support 

•  PC  to  PC  connectivity  for  data  transfer  and  resource 
sharing 

•  Distributed  processing  support  for  remote  locations 

•  PC  to  mainframe  connectivity  for  data  upload/download 
using  3270  emulation  on  the  PCs 

Additional  inherent  characteristics  like  protocol  indepen¬ 
dence,  redundancy,  multi-point  capability,  plus  diagnostics 
and  remote  network  control  from  a  central  location  were  also 
used  to  select  this  particular  LAN.  The  specifications 
concentrated  heavily  on  technical  interface  requirements 
while  not  trying  to  predict  or  characterize  user 
requirements. 

It  should  be  obvious  that  this  test  configuration 
assumed  MCDN  would  be  the  desired  long  distance  network  and 
centralized  host  data  processing  would  continue  to  be  the 
USMC  data  processing  strategy.  This  is  supported  by  the 
requirement  for  synchronous  3270  terminals  to  coexist  with 
personal  computers  which  used  3270  emulation  for  host  inter¬ 
face  connection.  The  overall  results  of  the  test  [ Ref.  25: 
Enel  4]  reinforce  the  ideas  presented  in  this  thesis,  most 
notably,  1)  the  selection  of  any  LAN  must  be  done  to  satisfy 
the  end  user's  requirements  and  not  based  solely  upon  tech¬ 
nical  considerations  and  2)  any  LAN  utilized  by  the  Marine 
Corps  should  be  one  with  full  connectivity.  Table  X  shows 
the  recommended  list  of  minimal  specif ications  generated  by 
specific  test  results.  Recommended  selection  criteria  like 
this  can  be  used  as  a  good  source  of  support  information  for 
the  Marine  Corps  networking  and  data  processing  strategy 


decisions.  Publication  of  these  items  alone  however,  will 
not  guarantee  commonalty,  compatibility,  or  even  interoper¬ 
ability  among  USMC  LANs.  This  is  especially  true  for  those 
procured  independently  by  various  individual  organizations. 
Their  broad  and  basic  nature  alone  opens  the  door  to  a 
multitude  of  different  solutions  yet  the  wide  variety  of 
features  they  demand  could  drive  any  vendor  solution  beyond 
the  reasonable  budget  of  those  interested  in  them.  This 
kind  of  test  effort  should  be  taken  one  step  further.  Once 
the  network  is  operational,  representative  samples  of  user 
application  traffic  should  be  introduced  with  network 
connectivity  as  close  to  realistic  as  possible.  In  this 
manner  cominor  USMC  applications  needs,  and  perhaps  standard 
solutions  could  be  identified.  Only  tests  like  this  will 
identify  interface  and  protocol  deficiencies  which  need  to 
be  corrected  to  ensure  the  desired  connectivity  and 
interoperability. 

C.  THE  SINGLE  SPECIFICATION  APPROACH 

The  U.  S.  Air  Force  has  been  studying  local  networks 
since  the  early  80 ' s.  They  recognized  the  need  to  create  a 
networking  architecture  and  set  of  standards  for  the  diverse 
set  of  computers,  operating  systems,  and  applications 
currently  in  use  or  being  developed.  The  result  of  their 
study  efforts  has  been  the  decision  to  create  a  single 
program  for  local  area  network  procurement.  The  objective 
of  the  Unified  Local  Area  Network  Architecture  (ULANA) 
Program  is  to  introduce  standard  LANs  into  the  Air  Force 
functional  areas  and  bases  in  a  unified  manner.  This  will 
be  done  through  a  comprehensive  set  of  common  specifications 
for  standard  hardware  and  software  operating  system  prod¬ 
ucts.  These  products  will  be  used  for  intra-base  informa¬ 
tion  flow  among  end-user  devices,  dedicated  systems,  shared 
systems,  and  gateways  to  other  information  transfer  systems. 
The  standard  specifications  will  then  be  used  as  the 
contractual  tools  for  LAN  procurement  and  implementation. 


TABLE  X 

RECOMMENDED  LAN  SPECIFICATIONS  FROM  MARCH  1985 
RASC  CAMP  PENDLETON  LAN  TEST 


The  LAN  must  be  protocol  independent  in  order  to 
support  full  connectivity,  therefore  communication 
between  devices  is  dependent  upon  device  software. 

Minimum  backbone  speed  should  not  be  less  than  10 
mbps  with  the  capability  to  select  the  port  output 
speed  to  the  user  ( range  of  3C0  to  9oC0  bps  at 
least). 

Must  be  capable  of  supporting  3270  bi-synchronous 
communications  where  each*  controller  is  supported  in 
a  multi-drop  configuration. 

User  must  be  able  to  communicate  to  the  network 
server  to  request  connections  to  1)  host  systems,  2) 
other  similar  devices,  and  3)  servers. 

Expected  data  traffic  which  must  be  supported: 

a)  Synchronous  short  bursty  messages 

b)  Synchronous  long  regular  messages  (file  transfers 
between  PCs  and  PC  to  host) 

c)  Asynchronous  file  transfers  between  PCs 

d)  Both  intelligent  and  non-intelligent  devices 

e)  3i-syr.chronous  and  SDLC  protocols 

f)  2780  RJE  file  transfers 

Minimal  supported  devices  is  500  where  a  supportable 
device  could  be  a  terminal  controller  with  up  to  32 
devices. 

Minimal  distance  between  devices  is  2000  feet  to 
avoid  signal  regeneration  without  having  a  device  in 
place. 

LAN  should  be  capable  of  supporting  a  minimum  of  4 
miles  of  cable  plant. 

Additions  to  the  network  should  be  possible  without 
disrupting  service  to  other  users. 

LAN  must  be  user  friendly  in  that  a  minimum  of  two  to 
three  simple  commands  are  recruired  to  establish  a 
connection*  to  another  device.  'This  implies  some  type 
of  network  server  capabilities  inherent  to  the  LAN. 


TABLE  X 


RECOMMENDED  LAN  SPECIFICATIONS  FROM  MARCH  1985 
RASC  CAMP  PENDLETON  LAN  TEST  (cont) 


11.  LAN  must  have  inherent  intelligent  bridges  which 

allow  for  inter-LAN  communication.  Also, 

caoabilities  should  exist  which  allow  for 
inter-Network  communication  across  the  CCMTZN.  This 
requirement  will  require  a  Marine  Corps  wide  adoption 
of  a  bridging  standard. 

12.  The  following  minimal  diagnostic  capabilities  must 
exist: 

a)  Fault  detection  -  LAN  must  recognize  when  a  cable, 
access  eouiDment,  or  attached  device  has  failed. 
This  information  must  be  provided  at  a  central 
location. 

b)  Fault  isolation  -  caoabilities  must  exist  to  allow 
a  technician  to  narrow  down  oroblem  determination 
to  the  failing  component  or  area. 

c)  Network  degradation  -  caoabilities  must  exist  to 
monitor  LAN  oerformance  in  terms  of  backbone  speed 
and  access  port  speeds. 

13.  LAN  must  be  caoable  of  establishing  virtual  circuit 
connections  between  devices.  This  reature  is  a  given 
for  almost  all  LANs,  but  re- stating  can  not  hurt. 

14.  Must  be  caoable  of  operating  off  standard  house 
current. 

15.  Vendor  should  be  able  to  provide  the  following: 

a)  Training  -  on  site  training  for  telet recessing 
technicians  and  software  orogranners.  Minimum  o: 
two  days  of  assistance  ana  instruction. 

b)  Maintenance  -  caoable  of  resocr.ding  to  a  trouble 
call  within  two  hours  and  sufficient  repair  parts 
available  to  effect  repairs  within  one  day. 

c)  Delivery  -  caoable  of  delivering  ecuicment  within 
50  days  of  receipt  of  purchase  order  aha  equipment 
must  oe  off  the  shelf. 

16.  LAN  must  be  caoable  of  switching  at  the  device  level. 
This  caoabilitv  must  be  able  to  be  overridden  from  a 
central' control  location  ( i. e.  Network  Control). 

17.  Access  security  at  the  device  level  must  be  at  least 
three  stages.  In  other  works,  central  control  can 
limit  what  switching/ access  caoabilities  each  user 
has  (  i.e.  between  uANs,  to  servers,  soeed  ,  type  of 
protocol ,  etc.  ) . 

18.  Capable  of  sustaining  a  single  failure  without 
disrupting  the  entire  network. 


The  following  is  the  list  of  these  tools: 


Standard  System  Specif j 
overall  architecture  anc 


ition  -  rules 
:unctioning  of 


Standard  Cable  Plant  Design  Specification  -  perform¬ 
ance,  monitoring" and  maintenance  standard  for  a  common 
transmission  media  (broadband  with  options  for  twisted 
pair  and  fiber  optics) 

Prototype  CAD /CAE  Station  -  a  prototype  system  for 
engineering  and  designing  dual  coaxial  broadband  cable 


engineering  and  designing  dual  coaxial  broadband  cable 
plants  for  LANs  using  computer  aided  design/computer 
aided  engineering  technologies 

•  Standard  Network  Interface  and  Interconnects  Units  -  a 
family  of  hardware/software  devices that  allows  TEhe 
subscribers  to  connect  various  information  processing 
(subscriber  devices)  to  the  network 

•  Standard  Network  Management  System  -  the  ULANA  networks 
operational",  supervisory,  and  control  hardware  and 
software 

•  ULANA  Management  System  (UMS)  -  an  Air  Force  central¬ 
ized  system  which  provides"  data  to  Air  Force  Personnel 
regarding  LAN  user  requirements,  operations,  perform¬ 
ance,  maintenance,  and  other  management  functions. 

If  realized,  the  ULANA  network  standard  network  inter¬ 
face  units,  cable  plants,  bridges,  gateways,  plus  opera¬ 
tional,  supervisory,  and  control  software  will  permit  the 
interconnection  of  a  variety  of  diverse  electronic  devices. 
Mainframe  computers,  minicomputers,  microcomputers,  termi¬ 
nals,  printers,  television  cameras,  television  receivers, 
telephones,  and  sensing  equipment  will  be  connected  through 
five  different  communications  subnets.  Figure  4. 1  shows  the 
frequency  assignments  that  will  allow  data,  host,  control, 
switched,  and  video  subnets  to  share  the  broadband  frequency 
range.  The  data  services  will  use  both  a  fixed  frequency 
band  (138-174  MHZ)  and  a  frequency  selectable  band  (216-312 
MHZ).  Switched  voice  and  video  service  requirements  will 


five  different  communications  subnets. 


range. 


use  312-348  MHZ. 


All  of  this  will  be  done  on  a  cable  that 


is  also  capable  of  simultaneously  handling  the  standard  FM 
voice  band  and  public  television  broadcast  video  channels  if 
desired.  The  Broadband  cable  plant  uses  a  common  segmented 
tree  topology  with  dual  coaxial  cables  connected  through 
multiple  redundant  headend  devices  for  building  and  base 
connectivity  (Figure  4.2). 


This  is  a  far  sighted  local  area  communications  system 
architecture.  It  allows  simultaneous  interconnection  of  a 
wide  variety  of  user  applications.  It  also  offers  the 
ability  to  transition  to  a  smaller  number  of  subnets  should 
any  of  these  applications  be  able  to  use  common  transmission 
techniques  and  protocols  in  the  future. 

Regardless  of  whether  the  U. S.  Marine  Corps  elects  to 
publish  a  common  set  or  specifications  and  selection 
criteria  or  a  common  set  of  standards  and  guidelines,  the 
more  hardware  and  software  parts  of  the  system  that  can  be 
standardized,  the  better  the  chances  for  interoperability  as 
well  as  economic  support.  No  one  solution  may  suit  all 
situations,  but  augmenting  user  specific  requirements  with 
other's  prototype  experiences  will  help  select  the  best 
solution.  Independent  network  analysis  tests  and  results 
will  also  decrease  the  chance  of  selecting  a  network  that 
does  not  meet  the  specified  requirements. 


The  emergence  of  the  microcomputer  as  a  powerful 
personal  productivity  tool  was  probably  most  instrumental  in 
the  move  away  from  large  costly,  centralized  mainframe 
processing  systems.  3etter  accessability,  greater  interac¬ 
tion,  and  a  wider  choice  of  equipment  are  all  advantages  of 
the  new  personal  computer  (PC)  technology.  However,  prob¬ 
lems  like  expensive  peripherals,  lack  of  data  file  integrity 
from  one  station  to  another,  inability  to  easily  share 
information,  and  database/program  maintenance  have  driven 
users  and  network  designers  toward  the  search  for  cost 
effective  ways  to  link  these  disparate  information 
processing  and  storage  tools.  Local  area  networks  (LANs) 
are  fast  becoming  the  logical  evolutionary  step  in  develop¬ 
ment  of  a  shared  multi-user  network  to  satisfy  this 
connectivity  requirement. 

LAM  vendors  offer  a  wide  variety  of  topologies,  control 
structures,  media,  access  control  techniques,  and  other 
items  designed  to  satisfy  individual  needs.  They  offer  the 
potential  for  more  flexible  connectivity  among  processors, 
workstations,  storage  devices,  and  expensive  peripherals  in 
the  local  area.  These  features  are  offered  at  greater 
speeds  and  lower  cost  than  possible  in  the  previous  host- 
dependent  data  processing  environment.  None,  however,  have 
come  up  with  a  design  that  looks  like  it  will  become  the 
standard  or  clear  cut  solution  to  everyone's  needs.  This 
has  caused  a  great  deal  of  confusion  on  the  part 
of  prospective  buyers.  It  has  also  resulted  in 
procurement  and  installation  of  many  heterogeneous 
networks  that  cannot  support  the  same  kind  of  equip¬ 
ment  or  cannot  intercommunicate. 


Independent  individual  procurement  was  an  acceptable 
strategy  for  PCs  because  their  cost  was  not  particularly 
high-  Organizations  basically  used  them  to  improve  produc¬ 
tivity  within  their  own  span  of  control  having  little  or  no 
affect  on  others.  LAN  networks  require  costly  special 
cables,  interface  devices,  and  sophisticated  servers.  These 
costs  along  with  individually  purchased  maintenance  and 
support;  contracts  are  rapidly  off- setting  the  advantages  of 
low  cost,  intelligent,  individual  workstations  over  the 
traditional  mainframe  approach. 

The  lack  of  official  guidance  along  with  inflated  vendor 
claims  have  created  groups  of  "system  hunters"  who  develop 
broad  or  superficial  user  requirements.  They  then  compare 
and  evaluate  the  capabilities  of  existing  hardware  and  soft¬ 
ware  solutions  to  satisfy  these  requirements.  A  thorough 
definition  of  user  needs  is  never  accomplished.  This  bottom 
up  approach,  using  broad  general  user  requirement  specifica¬ 
tions  and  lower-level  technical  considerations,  just  gives 
the  vendor  an  opportunity  to  submit  an  abundance  of  detail 
on  the  features  of  his  own  system.  He  never  translates 
those  features  into  required  operational  performance  capa¬ 
bilities.  The  network  is  essentially  specified  by  the 
vendor's  description  of  what  it  could  do  vice  the  user's 
detailed  description  of  what  was  needed.  These  networks 
have  few  problems  passing  operational  acceptance  criteria. 
It  is  only  after  network  installation  and  acceptance  that 
the  supported  organizations  discover  other  issues  which 
should  have  been  resolved  prior  to  or  during  the  LAN 
specification/selection  process.  The  specification  and 
selection  of  these  networks  deserves  more  detailed  consider¬ 
ation  and  guidance  than  broadly  specified  user  requirements 
augmented  by  technical  specifications  detailing  vendor 
strategies  that  already  exist. 


A  more  appropriate  strategy  is  one  that  adopts  a  system 
versus  component  approach  looking  at  things  from  the  top 
down  rather  than  the  bottom  up.  A  close  partnership  between 
users  and  information  system  professionals  is  essential. 
You  need  to  characterize  the  applications  or  end  user 
requirements  to  be  supported,  the  local/long  distance  inter¬ 
connection  and  communications  services  required  by  user 
applications,  and  the  technology  available  to  support  these 
requirements  in  that  order. 

The  characterization  of  user  requirements  should  be  done 
first  from  a  functional  not  necessarily  technical  stand¬ 
point.  Obviously  technical  terms  are  often  necessary  to 
describe  the  application,  but  emphasis  should  be  on  the  need 
first  not  the  solution.  Mistakenly,  people  often  say  they 
have  a  requirement  for  a  LAN.  A  LAN  is  not  a  requirement  but 
rather  one  element  in  a  list  of  potential  solutions  for 
satisfying  an  information  processing  and  transfer  require¬ 
ment.  Information  processing  and  transfer  requirements  must 
be  characterized  through  analysis  of  prospective  user 
mission  and  mission  functional/subfunctional  responsibili¬ 
ties  in  the  lowest  detail  possible.  The  analysis  of  current 
organizational  and  operational  management  information  struc¬ 
tures,  sources,  and  data  flow  techniques  used  to  handle 
these  mission  functions  is  then  added.  This  facilitates 
identification  of  deficiencies  as  well  as  connectivity  and 
processing  capabilities  that  already  exist. 

A  new  emphasis  is  needed  to  ensure  users  understand 
their  own  needs  well  enough  to  completely  and  accurately 
define  them  for  network  designers.  This  emphasis  also  gives 
them  the  opportunity  to  better  understand  the  existing 
information  management  system.  A  poorly  designed  and 
managed  information  system  is  just  as  big  a  contributor  to 
problems  as  isolated  information  processing  and  standalone 
PCs.  As  individuals  or  parts  of  the  organization  become 


more  productive,  it  affects  everyone  else  whose  work  is 
connected  to  them.  Adequate  planning  and  preparation  is 
essential  to  address  changes  in  work  responsibilities  and 
behavior  patterns,  accommodate  user  concerns,  and  allow 
smooth  transition  to  new  capabilities.  Moving  information 
between  user  applications  without  labor  intensive  interme¬ 
diate  handling  or  reformatting  in  a  manner  that  supports  the 
way  people  really  work  and  think  will  be  the  key  to  success. 

The  identity  of  individual  subfunctions  must  be 
preserved  for  future  development  of  specifications  as  well 
as  test  and  evaluation  criteria.  These  functions  can 
however,  be  grouped  in  common  applications  and  higher- level 
services.  Various  information  systems  use  application 
processes  or  logical  elements  called  protocols  to  perform 
the  services  required  by  specific  user  applications.  The 
exchange  of  information  among  data  transfer  systems  is  a 
complicated  process.  The  required  cooperation  must  be 
formalized  in  rules  which  define  the  methods,  procedures, 
and  conventions  needed  to  complete  the  information  exchange. 
Standards  at  the  network  layer  and  above  are  critical  for 
compatibility  and  communications  LAN  to  LAN  and  LAN  to  WAN. 
USMC  programmers  and  engineers  will  not  likely  write  proto¬ 
cols  that  support  user  applications  or  communications  inter¬ 
faces.  However,  we  should  develop  a  method  to  evaluate 
where  specific  protocol  services  fit  within  the  general 
OSI/RM  and  whether  they  fit  our  needs.  The  keen  competi¬ 
tion  for  diminishing  research,  development,  production  and 
operating  funds  almost  mandates  procurement  of  existing 
off-the-shelf  network  and  processing  components  to  reduce 
development  costs  and  allow  economic  logistics  and  mainte¬ 
nance  support.  This  should  not  however,  reduce  our  efforts 
to  properly  define  our  actual  requirements  to  ensure  we  get 
a  system  that  meets  our  needs  yet  does  not  have  expensive 
unnecessary  features  accepted  just  because  they  were 
available. 


As  local  network  capabilities  grow,  so  will  the  desire 
to  expand  the  geographic  coverage  of  the  systems  providing 
these  capabilities.  This  will  increase  the  need  for  both 
local  and  long  distance  LAN  interconnection.  If  not 
adequately  addressed  in  the  planning  stages  of  LAN  design, 
the  result  will  be  efficient  pockets  of  high  speed  data 
processing  and  data  communication  systems  that  are  seriously 
degraded  by  inefficient  interconnection  solutions.  There 
are  many  different  established  long  distance  network  proto¬ 
cols  (INTERNET,  SNA,  DNA,  etc).  The  Marine  Corps  should 
develop  an  overall  data  processing  and  long  distance  network 
interconnection  strategy.  This  will  ensure  that  unnecessary 
expensive  connection,  bridges,  gateways,  and  protocol 
conversion  requirements  are  not  imposed  on  all  LAN  specifi¬ 
cations  just  to  cover  all  the  contingencies.  Will  data 
processing  continue  to  be  the  centralized  host  oriented 
operation  it  is  today  or  will  a  more  distributed  operation 
be  adopted  in  the  future?  Will  DDN,  MCDN,  PSNs,  or  a  combi¬ 
nation  of  all  three  be  used  for  long  distance  interconnec¬ 
tion?  Since  most  LAM  traffic  is  local,  these  parameters  may 
not  be  the  driving  force  in  LAN  access  and  communication 
strategies  but  they  cannot  be  ignored.  This  reduces  the 
chance  of  selecting  a  LAN  that  is  rendered  woefully  ineffi¬ 
cient  or  even  worse  cannot  pass  traffic  when  connected  to  a 
long  distance  network. 

Once  a  LAN  is  the  technology  selected,  expected  LAN 
oriented  performance  characteristics,  facilities  and 
support,  network  management,  security  and  any  other  needed 
features/constraints  should  be  added.  This  results  in  prep¬ 
aration  of  a  more  accurate  and  complete  specification  docu¬ 
ment  for  the  solicitation  package.  Modular  design 
techniques  will  ensure  that  the  entire  system  does  not 
require  replacement  all  at  once.  Commercially  available 
parts  and  software  tools  reduce  supportability  costs. 


Contractual  flexibility  is  the  key  to  substituting  modern 
components  during  the  life  of  the  contract.  Technology 
should  be  used  to  reduce  manpower  intensive  operations. 
Simply  substituting  newer  versions  of  existing  physical 
systems  or  even  worse  adding  additional  systems  is  not  the 
solution. 

Who  will  provide  the  day-to-day  maintenance  and  network 
control  support  for  LANs?  Once  again  an  overall  Marine 
Corps  maintenance  strategy  is  in  needed.  If  local  networks 
really  will  become  an  integral  part  of  the  Marine  Corps' 
data  processing  and  communications  network  strategy,  then 
appropriate  staffing  and  facilities  improvements  to  existing 
organizations  must  be  planned.  Perhaps  not  every  LAN  will 
need  a  dedicated  network  control  center,  but  the  lowest 
level  with  a  full  time  manned  center  should  be  identified 
and  subordinate  network  administrative,  maintenance,  and 
operational  responsibilities  should  be  formalized. 

The  specified  requirements  should  be  directly  translated 
into  evaluation  criteria  for  selecting  from  the  various 
vendor  proposals.  No  one  solution  may  suit  all  situations. 
However,  augmenting  user  specific  requirements  with  other's 
prototype  experiences  as  well  as  independent  network  anal¬ 
ysis  and  test  results  will  decrease  the  chance  of  selecting 
a  network  that  does  not  meet  specified  requirements 

Execution  of  all  the  steps  and  procedures  addressed  in 
this  thesis  for  each  and  every  LAN  procurement  would  be  very 
costly  in  terms  of  time  and  money.  A  centrally  controlled 
database  should  be  created  to  act  as  a  repository  of  infor¬ 
mation  for  prospective  LAN  users,  designers,  and  procurement 
specialists.  This  could  greatly  reduce  the  research  and 
analysis  effort  required.  Those  with  like  or  identical 
requirements  to  existent  prototype  or  operational  LANs  could 
take  advantage  of  lessons  learned,  problems  solved,  and 
tried  and  tested  procedures  and  specifications.  This 


ACRONYMS 


AFB  -  Air  Force  Base 

AIS  -  Automated  Information  System 

BPS  -  Bits  per  second 

CAD  -  Computer  Aided  Design 

CAE  -  Computer  Aide  Engineering 

CATV  -  Community  Antenna  Television 

CBX  -  Computerized  Branch  Exchange 

CCITT  -  International  Telegraph  and  Telephone  Consultive 
Committee 

CD  -  Collision  Detection 

CEO  -  Communication  Electronics  Officer 

CPU  -  Central  Processing  Unit 

CSMA  -  Carrier  Sense  Multiple  Access 

DCA  -  Defense  Communications  Agency 

DCE  -  Digital  Circuit  Switching  Equipment 

DDCMP  -  Digital  Data  Communications  Message  Protocol 

DDN  -  Defense  Data  Network 

DEC  -  Digital  Equipment  Corporation 

DES  -  Data  Encryption  Standard 

DMA  -  Digital  Network  Architecture 

DOD  -  Department  of  Defense 


Digital  Terminal  Equipment 

Front  End  Processor 

Frequency  Modulation 

File  Transfer  Access  and  Management 

Institute  of  Electrical  and  Electronic  Engineers 

Internet  Protocol 

International  Standards  Organization 

Kilobits  per  second 

Kilohertz 

Local  Area  Network 
Megabits  per  second 
Marine  Corps  Data  Network 
Megahertz 

Network  Addressable  Unit 

National  Security  Agency 

Network  Services  Protocol 

Open  System  Interconnection 

Private  Automatic  Branch  Exchange 

Private  Branch  Exchange 

Personal  Computer 
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SDLC  -  Synchronous  Data  Link  Control 

SSCP  -  System  Services  Control  Point 

TCP  -  Transmission  Control  Protocol 
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